[llvm-commits] [llvm] r169459 - in /llvm/trunk: include/llvm/Target/TargetLowering.h lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/CodeGen/SelectionDAG/TargetLowering.cpp lib/Target/ARM/ARMISelLowering.cpp lib/Target/ARM/ARMISelLowering.h lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h test/CodeGen/ARM/extload-knownzero.ll

[Evan Cheng]

r169536

Evan

On Dec 6, 2012, at 9:00 AM, Evan Cheng <evan.cheng at apple.com> wrote:

> I think you are right. It's not safe to compute known zero for anyext until just before selection time. I'll look into solving this deficiency another way. 
> 
> Thanks,
> 
> Evan
> 
> On Dec 6, 2012, at 1:00 AM, Duncan Sands <baldrick at free.fr> wrote:
> 
>> Hi Evan,
>> 
>> On 06/12/12 02:28, Evan Cheng wrote:
>>> Author: evancheng
>>> Date: Wed Dec  5 19:28:01 2012
>>> New Revision: 169459
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=169459&view=rev
>>> Log:
>>> Let targets provide hooks that compute known zero and ones for any_extend
>>> and extload's. If they are implemented as zero-extend, or implicitly
>>> zero-extend, then this can enable more demanded bits optimizations. e.g.
>> 
>> is this correct?  All kinds of DAG combines exploit that anyext means "any",
>> eg: any_extend(trunc X) -> X.  On a target where any_extend does zero-extend,
>> won't your patch say that all the upper bits of "any_extend(trunc X)" are
>> zero, causing all kinds of oddness when they turned later into the bits of X,
>> which may not be zero.
>> 
>> Ciao, Duncan.
>> _______________________________________________
>> 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