search for: beforelegalizetypes

Hi, I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. Vector legalization that comes afterwards just scalarized the operation. SelectionDAGISel::CodeGenAndEmitDAG() .. CurDAG->Combine(BeforeLegaliz...

On Mon, Feb 6, 2012 at 11:54 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. > I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. > Vector legalization that comes afterwards just scalarized the operation. > > SelectionDAGISel::CodeGenAndEmitDAG() > .. >   CurDAG-&g...

At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND gives me the new chain LOAD -> ANY_EXTEND -> AND. I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). Combine(AfterLegalizeTypes) is no called at all. - Elena -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmai...

On Tue, Feb 7, 2012 at 12:38 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. > After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND  gives me the new chain LOAD -> ANY_EXTEND -> AND. > > I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). That sounds like it's just a matter of making sure we don't forget to add the ANY_EXTEND to the worklist. We don'...

Hi Sanjay, thanks for this information. I did get a little bit further with the patch. However, Hexagon gives me headaches. I tried to limit the scope of the patch to the BeforeLegalizeTypes phase and Hexagon still reaches the unreachable. Hexagon tries to split or widen a vector type for a node with custom lowering where the unreachable arises from inside TargetLowering::ReplaceNodeResults which is not overwritten in the Hexagon backend. To avoid generating illegal code after all...

...On Thu, Sep 21, 2017 at 10:06 PM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches. > > I tried to limit the scope of the patch to the BeforeLegalizeTypes phase > and Hexagon still reaches the unreachable. Hexagon tries to split or > widen a vector type for a node with custom lowering where the > unreachable arises from inside TargetLowering::ReplaceNodeResults which > is not overwritten in the Hexagon backend. > > To avoid generati...

...enster.de <mailto:michael.haidl at uni-muenster.de>> > wrote: > > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches. > > I tried to limit the scope of the patch to the BeforeLegalizeTypes phase > and Hexagon still reaches the unreachable. Hexagon tries to split or > widen a vector type for a node with custom lowering where the > unreachable arises from inside TargetLowering::ReplaceNodeResults which > is not overwritten in the Hexagon backend. > >...

There are multiple problems/questions here: 1. Make sure you've updated trunk to the latest rev before running update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the output you're seeing if you're running the script on a version of that test file before r313631. After that commit, each RUN has its own check prefix, so there should be no conflict opportunity. 2. I