[clang] [clang][codegen] Don't mark "int" TBAA on FP libcalls with indirect args (PR #108853)

[Zahira Ammarguellat via cfe-commits]

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