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

[Rafael Espíndola]

Cool, thanks for the explanation. I reported pr19893 to keep track of it.

On 29 May 2014 15:45, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote:
> 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
>>
>