[llvm-commits] [llvm] r60608 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86Subtarget.cpp lib/Transforms/Scalar/LoopStrengthReduce.cpp test/CodeGen/X86/loop-strength-reduce-2.ll test/CodeGen/X86/loop-strength-reduce-3.ll test/CodeGen/X86/loop-strength-reduce.ll

[Evan Cheng]

On Dec 5, 2008, at 2:23 PM, Dale Johannesen wrote:

>
> On Dec 5, 2008, at 2:01 PMPST, Anton Korobeynikov wrote:
>
>> Hi, Dale
>>
>>>
>>> +/// True if accessing the GV requires a register.  This is a
>>> superset of the
>>> +/// cases where GVRequiresExtraLoad is true.  Some variations of
>>> PIC require
>>> +/// a register, but not an extra load.
>>> +bool X86Subtarget::GVRequiresRegister(const GlobalValue *GV,
>>> +                                       const TargetMachine& TM,
>>> +                                       bool isDirectCall) const
>>> +{
>>> +  if (GVRequiresExtraLoad(GV, TM, isDirectCall))
>>> +    return true;
>>> +  // Code below here need only consider cases where
>>> GVRequiresExtraLoad
>>> +  // returns false.
>>> +  if (TM.getRelocationModel() == Reloc::PIC_)
>>> +    return !isDirectCall &&
>>> +      (GV->hasInternalLinkage() || GV->hasExternalLinkage());
>> I don't understand this. Why only internal and external linkage?
>
> All the others are already handled by GVRequiresExtraLoad.  (At least
> for Darwin.)

That doesn't sound right. For Darwin x86 32-bit PIC, all data load  
requires the pic base register. This has nothing to do with whether a  
stub is needed.

Evan

>
>
>> Actually for PIC on Linux (32 bit only) access to every symbols,
>> except ones with internal linkage or hidden visibility requires a GOT
>> register access. There was even special hook inside
>> X86ISelLowering.cpp (incomplete in general, but usable -
>> CallRequiresGOTPtrInReg() and another one around) for this sort of
>> thing. Please consider using it.
>
> This applies to data objects, not calls.  The rules are fairly
> different for calls and data, and I'm not sure commonality is useful.
> The hook I'm interested in fixing is isLegalAddressingMode, which
> isn't calling into the Linux function you mention.
>
>> We've just ended with 3 hooks used
>> for more or less similar stuff.
>>
>> It will be nice to have all this in one place and in consistent
>> state...
>>
>> ---
>> With best regards, Anton Korobeynikov
>> Faculty of Mathematics and Mechanics, Saint Petersburg State
>> University
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits