[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
Dale Johannesen
dalej at apple.com
Mon Dec 8 14:02:00 PST 2008
On Dec 8, 2008, at 1:54 PMPST, Evan Cheng wrote:
>>>
>>> Any plan to change the code? It doesn't makes sense to perform the
>>> expensive checks first.
>>
>> It makes even less sense to make the code less comprehensible, and
>> possibly break it (as you have seen), for a microoptimization.
>> No, I
>> think this is a good use of factoring, and I don't plan to change it.
>>
>>> What about the first part of my comment? If PIC && !DirectCall, is
>>> PIC
>>> base ever unnecessary? From what I have see it's needed even if the
>>> linkage is weak, common, etc.
>>
>> Those cases are picked up by RequiresExtraLoad.
>
> I don't understand your argument. Why can't we satisfy both
> constraints?
There has been no mention of "constraints" so far, what do you mean?
> We know when isDirectCall this is always false, we also
> know it's always true in PIC mode (at least for Darwin). How is this
> less clear?
You're losing the separation between "things handled by
RequiresExtraLoad"
and "things not handled that way". There is overlap the way you've
got it.
> {
> if (isDirectCall)
> return false;
> if (TM.getRelocationModel() == Reloc::PIC_) {
> if (isTargetDarwin())
> return true;
> else if (isTargetElf())
> ...
> else ...
> ...
> }
> return GVRequiresExtraLoad(GV, TM, false);
> }
>
> Evan
>
>>
>>
>> _______________________________________________
>> 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
More information about the llvm-commits
mailing list