zahiraam wrote: > > > > How does this interact with #107598? > > > > > > > > > Though this also changes things to ensure when TBAA data is set, it's > > > always set on the call. > > > > > > Wasn't already doing that? (setting the TBAA on the call?). > > It was setting it on `cast<llvm::Instruction>(Call.getScalarVal())` not > necessarily the call (which you can get via an output on `EmitCall()`). At > least in this case that meant it was putting the TBAA metadata on the `load > x86_fp80` after the call. I'm not sure if there's other cases where something > similar could happen.
> > > > How does this interact with #107598? > > > > > > > > > Though this also changes things to ensure when TBAA data is set, it's > > > always set on the call. > > > > > > Wasn't already doing that? (setting the TBAA on the call?). > > It was setting it on `cast<llvm::Instruction>(Call.getScalarVal())` not > necessarily the call (which you can get via an output on `EmitCall()`). At > least in this case that meant it was putting the TBAA metadata on the `load > x86_fp80` after the call. I'm not sure if there's other cases where something > similar could happen. Without this patch and without (https://github.com/llvm/llvm-project/pull/107598) the function `pow` doesn't generate `int TBAA` info on the call, but it does on a call to `cargl` with `-triple aarch64-unknown-unknown`. `# | %call = tail call fp128 @cargl([2 x fp128] noundef alignstack(16) undef) #1, !tbaa !2` https://github.com/llvm/llvm-project/pull/108853 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
