llvm dev - Feb 2012 - [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

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