[PATCH] PowerPC support for the ELFv2 ABI (powerpc64le-linux)

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Sun Jul 20 17:26:09 PDT 2014

Hal Finkel <hfinkel at anl.gov> wrote on 20.07.2014 04:11:54:

> > Well, before the patch, we would
> > - load Arg into the FPR
> > - store Arg into the stack slot
> > - load the GPR from the stack slot
> >
> > After the patch, we instead
> > - load Arg into the FPR
> > - load Arg into the GPR (which under the covers may do a store/load
> >   to a temp slot)
> >
> > I don't see where this would be slower than before; in fact, if Arg
> > itself happens to be a memory load already, I'd expect the new way
> > to be faster even on pre-P8 and ELFv1 ...
> Ah, okay thanks. I agree, that sounds fine. Please make sure this is
> noted in the commit message.


> If the behavior is equivalent for the old IR-level constructs, then
> that's fine. I had thought it was changing (you were introducing
> extra GPR loads), but had just misread your code. Thanks for
clarifying :-)

No problem, good that we're in sync again :-)

> > Again, this is because I deliberately made the LLVM behavior
> > independent of ELFv1 vs. ELFv2; there is a comment in
> > functionArgumentNeedsConsecutiveRegisters that explains the
> > intended use of those array types by a front-end to implement
> > the ELFv2 calling convention.
> Fair enough. However, I'd appreciate some comments in
> PPCISelLowering too. Saying "See the comment in
> functionArgumentNeedsConsecutiveRegisters", is fine, but otherwise
> it is not obvious which parts of the code are specifically handling
> ELFv2 features, and which are generic.

OK, I've added a bunch more comments calling out the fact that (what
looks like) plain scalar types may originate from directly passed
array types, and what clang is using those for.

I've checked this in as revision 213493.


More information about the llvm-commits mailing list