search for: extvt

Displaying 10 results from an estimated 10 matches for "extvt".

Did you mean: eltvt
2015 Mar 03
3
[LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.
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 pass is target-independent yes? So that makes sense. The issue we are having is this: we don't sup...
2010 Jul 19
0
[LLVMdev] DAGCombiner::ReduceLoadWidth bug?
...fter type legalization, the DAG combiner should not introduce any illegal types. When running after operation legalization, the DAG combiner should not introduce any illegal operations. Consider this code from ReduceLoadWidth: if (LegalOperations && !TLI.isLoadExtLegal(ISD::SEXTLOAD, ExtVT)) return SDValue(); Here you see that it checks whether it is only allowed to produce legal operations, and bails out if it would create an illegal extending load. However the later logic in ReduceLoadWidth doesn't do any such checking as far as I can see, which is wrong. Ciao, Duncan...
2010 Jul 20
1
[LLVMdev] DAGCombiner::ReduceLoadWidth bug?
...he DAG combiner > should not introduce any illegal types. When running after operation > legalization, the DAG combiner should not introduce any illegal operations. > Consider this code from ReduceLoadWidth: > > if (LegalOperations&& !TLI.isLoadExtLegal(ISD::SEXTLOAD, ExtVT)) > return SDValue(); > > Here you see that it checks whether it is only allowed to produce legal > operations, and bails out if it would create an illegal extending load. > However the later logic in ReduceLoadWidth doesn't do any such checking > as far as I can see,...
2010 Jul 19
2
[LLVMdev] DAGCombiner::ReduceLoadWidth bug?
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 the result is to be /// extended, also fold the extension to form a
2011 Jul 27
0
[LLVMdev] Avoiding load narrowing in DAGCombiner
...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
2011 Jul 27
2
[LLVMdev] Avoiding load narrowing in DAGCombiner
...: >> >> 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 forward to trunk and stay there in a month or two), and 2.8 only had that check for SIGN...
2011 Jul 27
2
[LLVMdev] Avoiding load narrowing in DAGCombiner
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()
2011 Jul 27
0
[LLVMdev] Avoiding load narrowing in DAGCombiner
...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 forward to trunk and stay > there in a month or two), and 2.8 only had...
2015 Mar 03
2
[LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.
...cha at gmail.com> wrote: > On Tue, Mar 3, 2015 at 10:35 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in > > general): > > > > if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT)) > > return SDValue(); > > > > LegalOperations is false for the first pre-legalize pass and true for the > > post-legalize pass. The first pass is target-independent yes? So that > makes > > sense. > > > > The issue we are having is this: we don'...
2015 Mar 04
2
[LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.
...Mar 3, 2015 at 10:35 AM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> > I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in > >> > general): > >> > > >> > if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT)) > >> > return SDValue(); > >> > > >> > LegalOperations is false for the first pre-legalize pass and true for > >> > the > >> > post-legalize pass. The first pass is target-independent yes? So that > >> > makes > >&gt...