[llvm] r209638 - [PPC] Use alias symbols in address computation.

[Bill Schmidt]

Hi Rafael,

Sorry I didn't get a chance to answer this earlier -- have been stuck in
a lot of meetings this week.

On Wed, 2014-05-28 at 13:40 -0400, Rafael Espíndola wrote:
> > I don't have one. If you could try a bootstrap, that would be great.
> 
> The difference is from cases like
> 
> 
> define void @foo()  {
>   ret void
> }
> declare i32 @bar(i8*)
> define  void @zed() {
>   call i32 @bar(i8* bitcast (void ()* @foo to i8*))
>   ret void
> }
> 
> 
> trunk produces
>         addis 3, 2, .LC1 at toc@ha
>         ld 3, .LC1 at toc@l(3)
> 
> and the patch produces
> 
>         addis 3, 2, .LC1 at toc@ha
>         addi 3, 3, .LC1 at toc@l
> 
> So it looks like it decides to use a constant pool and then passes the
> address of the pool. If instead of a function we have a variable, both
> trunk and patch work by doing
> 
>         addis 3, 2, var at toc@ha
>         addi 3, 3, var at toc@l
> 
> that is, they don't create the constant pool entry.
> 
> It is easy to fix the patch to do a load for functions, but I wonder
> why it is considered better/necessary to create a constant pull for
> them. Couldn't we use
> 
>         addis 3, 2, func at toc@ha
>         addi 3, 3, func at toc@l
> 

Yes, when "func" is in the same compile unit, we can do this (and in
fact GCC does this today).  So this is an oversight in the LLVM PPC64
back end at the moment.  For externally defined functions, both GCC and
LLVM generate the addis/ld code using the constant pool entry.

I see that you've already committed changes that leave the function code
as is for now.  Thanks for doing that.  I'll take a note to have a look
at the local-function-address generation when time permits, unless
someone else gets to it first.

Thanks,
Bill

> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>