Demikhovsky, Elena
2012-Feb-07 07:54 UTC
[LLVMdev] DAG optimization and lowering algorithm
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(BeforeLegalizeTypes, *AA, OptLevel);
bool Changed;
Changed = CurDAG->LegalizeTypes();
if (Changed) {
CurDAG->Combine(AfterLegalizeTypes, *AA, OptLevel);
}
The problem does not exist if the function is bigger and something was changed
on LegalizeTypes() stage.
I think that Combine(AfterLegalizeTypes) should be called anyway, even if
LegalizeTypes() did not change anything.
- Elena
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
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->Combine(BeforeLegalizeTypes, *AA, OptLevel); > > bool Changed; > Changed = CurDAG->LegalizeTypes(); > > if (Changed) { > CurDAG->Combine(AfterLegalizeTypes, *AA, OptLevel); > } > > The problem does not exist if the function is bigger and something was changed on LegalizeTypes() stage. > > I think that Combine(AfterLegalizeTypes) should be called anyway, even if LegalizeTypes() did not change anything.We skip the extra run as a performance optimization... we really don't want extra runs of DAGCombine if we can avoid it. If there is some optimization that currently only runs after type legalization, perhaps we can change it? -Eli
Demikhovsky, Elena
2012-Feb-07 08:38 UTC
[LLVMdev] DAG optimization and lowering algorithm
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 gmail.com] Sent: Tuesday, February 07, 2012 10:15 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] DAG optimization and lowering algorithm 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->Combine(BeforeLegalizeTypes, *AA, OptLevel); > > bool Changed; > Changed = CurDAG->LegalizeTypes(); > > if (Changed) { > CurDAG->Combine(AfterLegalizeTypes, *AA, OptLevel); > } > > The problem does not exist if the function is bigger and something was changed on LegalizeTypes() stage. > > I think that Combine(AfterLegalizeTypes) should be called anyway, even if LegalizeTypes() did not change anything.We skip the extra run as a performance optimization... we really don't want extra runs of DAGCombine if we can avoid it. If there is some optimization that currently only runs after type legalization, perhaps we can change it? -Eli --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Elena,> 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).why all these restrictions? What is the node, what created it, and what do you want done with it? Ciao, Duncan. 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(BeforeLegalizeTypes, *AA, OptLevel); > > bool Changed; > Changed = CurDAG->LegalizeTypes(); > > if (Changed) { > CurDAG->Combine(AfterLegalizeTypes, *AA, OptLevel); > } > > The problem does not exist if the function is bigger and something was changed on LegalizeTypes() stage. > > I think that Combine(AfterLegalizeTypes) should be called anyway, even if LegalizeTypes() did not change anything. > > > - Elena > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev