search for: reduceloadwidth

DAGCombiner::ReduceLoadWidth() does the following: /// ReduceLoadWidth - If the result of a wider load is shifted to right of N /// bits and then truncated to a narrower type and where N is a multiple /// of number of bits of the narrower type, transform it to a narrower load /// from address + N / num of bits of new type. If...

Hi JP, > DAGCombiner::ReduceLoadWidth() does the following: > /// ReduceLoadWidth - If the result of a wider load is shifted to right of N > /// bits and then truncated to a narrower type and where N is a multiple > /// of number of bits of the narrower type, transform it to a narrower load > /// from address + N / num of b...

On 7/19/10 10:36 AM, Duncan Sands wrote: > Hi JP, > > >> DAGCombiner::ReduceLoadWidth() does the following: >> /// ReduceLoadWidth - If the result of a wider load is shifted to right of N >> /// bits and then truncated to a narrower type and where N is a multiple >> /// of number of bits of the narrower type, transform it to a narrower load >> /// from addres...

I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in general): if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT)) return SDValue <http://llvm.org/docs/doxygen/html/classllvm_1_1SDValue.html>(); LegalOperations is false for the first pre-legalize pass and true for the post-legalize pass. The first pas...

...9;s crashing because LD1 is produced due to LegalOperations=false in pre-legalize pass. Then Legalization does not know how to handle it so it asserts on a default case. I don't know if it's a reasonable expectation or not but we do not have support for it. I have not tried overriding shouldReduceLoadWidth. 2) I see, that makes sense to some degree, I'm curious if you can provide an example? It doesn't seem good to generate something pre-legalize (target-independent) that you can't then handle when you find that it's illegal in the very next step that is legalization. I'm guessin...

...; > asserts on a default case. > > Yes, and where, and on what, does the assert fire? 8-bit load > legalization I assume? > > > I don't know if it's a reasonable expectation or > > not but we do not have support for it. I have not tried overriding > > shouldReduceLoadWidth. > > > > 2) I see, that makes sense to some degree, I'm curious if you can > provide an > > example? It doesn't seem good to generate something pre-legalize > > (target-independent) that you can't then handle when you find that it's > > illegal in th...

On Thu, Mar 5, 2015 at 4:19 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Thanks for the reply: > > So should LLVM continue to assume 8-bit byte addressing? It would be nice, > not only to us but potential future machines, to have a permanent fix to > this assumption? This sounds reasonable yes? > > Marking them as Custom in XXXISelLowering still produces error, the

On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Yes, it is breaking during the legalize phase, depending on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the

On Wed, Mar 4, 2015 at 11:43 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ahmed, > > Yes, we do not have an 8 bit type and do not support 8 bit loads/extloads. > > For your first post, I imagine that anything that the DAGCombiner does it > could undo EXCEPT deciding to opt to a type that is not allowed, No, I think the SelectionDAG legalization should be able to

> Hi Johannes, what processor are you targeting? Is it little-endian or > big-endian? Little-endian. (The truth: you can set it manually, but it is set to little endian, for sure.) The processor is a TI TMS320C64x. Follow-up: I discovered that the "guilty" method is DAGCombiner::ReduceLoadWidth. The error is introduced because the offset is not calculated correctly. The first problem is that the pointer I get for loading does not point to the address of the low word, but to the address of the high word. The second problem is that this is apparently correct as long as lddw is used inst...

...case, the LD4->SRL combo was emitted precisely because I *don't* want a > ZEXTLOAD i16.  I'm wondering if there is: > > a) A way to turn off this optimization in DAGCombine if your target > doesn't support LD2 natively This. I think you're talking about DAGCombiner::ReduceLoadWidth... and the "if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT))" is supposed to ensure that the transformation in question is safe. That said, IIRC I fixed a bug there recently; are you using trunk? -Eli

...itted precisely because I *don't* want a >> ZEXTLOAD i16. I'm wondering if there is: >> >> a) A way to turn off this optimization in DAGCombine if your target >> doesn't support LD2 natively > > This. > > I think you're talking about DAGCombiner::ReduceLoadWidth... and the > "if (LegalOperations&& !TLI.isLoadExtLegal(ExtType, ExtVT))" is > supposed to ensure that the transformation in question is safe. That > said, IIRC I fixed a bug there recently; are you using trunk? Perfect! I'm using 2.8 for now (am hoping to roll fo...

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()

...39;t* want a >>> ZEXTLOAD i16.  I'm wondering if there is: >>> >>> a) A way to turn off this optimization in DAGCombine if your target >>> doesn't support LD2 natively >> >> This. >> >> I think you're talking about DAGCombiner::ReduceLoadWidth... and the >> "if (LegalOperations&&  !TLI.isLoadExtLegal(ExtType, ExtVT))" is >> supposed to ensure that the transformation in question is safe.  That >> said, IIRC I fixed a bug there recently; are you using trunk? > > Perfect!  I'm using 2.8 for now...

Hi Johannes, what processor are you targeting? Is it little-endian or big-endian? Ciao, Duncan. > I have the following simple IR: > > ================================== > @l = common global i64 0, align 8 > > define void @hello() nounwind { > entry: > store i64 -4919131755279862989, i64* @l > ret void > } > > define i32 @main(i32 %argc, i8** %argv)

...cessor are you targeting?  Is it little-endian or >> big-endian? > Little-endian. (The truth: you can set it manually, but it is set to > little endian, for sure.) The processor is a TI TMS320C64x. > > Follow-up: I discovered that the "guilty" method is > DAGCombiner::ReduceLoadWidth. The error is introduced because the offset > is not calculated correctly. > > The first problem is that the pointer I get for loading does not point > to the address of the low word, but to the address of the high word. This is contradictory: on a little-endian processor, the address...

Hello! I have the following simple IR: ================================== @l = common global i64 0, align 8 define void @hello() nounwind { entry: store i64 -4919131755279862989, i64* @l ret void } define i32 @main(i32 %argc, i8** %argv) nounwind { entry: call void @hello() %tmp = load i64* @l %conv = trunc i64 %tmp to i32 ret i32 %conv } ==================================