search for: afterlegalizedag

Hello, I'm getting an instruction selection error because DAGCombiner is introducing an illegal node after the legalizeDAG phase. Basically this is what is going on: 1) During legalization, BR_JT gets expanded introducing a (mul x, 2). 2) After legalization (AfterLegalizeDAG), that (mul x, 2) is converted to an (shl x, 1). However, that shl node introduced is illegal, and since my custom lowering code won't run after this phase it gets into the instruction selector. I would like to know if this is really a bug or it has to be handled by the target code. I guess I...

...by DAGCombiner after legal phase Hello, I'm getting an instruction selection error because DAGCombiner is introducing an illegal node after the legalizeDAG phase. Basically this is what is going on: 1) During legalization, BR_JT gets expanded introducing a (mul x, 2). 2) After legalization (AfterLegalizeDAG), that (mul x, 2) is converted to an (shl x, 1). However, that shl node introduced is illegal, and since my custom lowering code won't run after this phase it gets into the instruction selector. I would like to know if this is really a bug or it has to be handled by the target code. I guess I...

...it, but my guess for the Hexagon crash (and probably other targets) is that you're trying to create illegal ops after the DAG has been legalized. So that's another potential way to limit the scope of the patch - don't try the transform unless we're pre-legalization: if (Level < AfterLegalizeDAG) { // do something } On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > Hi, > > I am currently working on a more or less intrusive patch (D37896), which > pulls optimizations on multiplications from some back-ends, e.g., (mul > x, 2...

...gon crash (and > probably other targets) is that you're trying to create illegal > ops after the DAG has been legalized. So that's another potential way to > limit the scope of the patch - don't try the transform unless we're > pre-legalization: >   if (Level < AfterLegalizeDAG) { // do something } > > > > On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael > <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > wrote: > > Hi, > > I am currently working on a more or less intrusive patch (D37896)...

...t; probably other targets) is that you're trying to create illegal > > ops after the DAG has been legalized. So that's another potential way to > > limit the scope of the patch - don't try the transform unless we're > > pre-legalization: > > if (Level < AfterLegalizeDAG) { // do something } > > > > > > > > On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael > > <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > > wrote: > > > > Hi, > > > > I am currently working...

...that you're trying to create illegal > > ops after the DAG has been legalized. So that's another potential > way to > > limit the scope of the patch - don't try the transform unless we're > > pre-legalization: > >    if (Level < AfterLegalizeDAG) { // do something } > > > > > > > > On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael > > <michael.haidl at uni-muenster.de > <mailto:michael.haidl at uni-muenster.de> > <mailto:michael.haidl at uni-muenster.de >...

Hi, I am currently working on a more or less intrusive patch (D37896), which pulls optimizations on multiplications from some back-ends, e.g., (mul x, 2^N + 1) => (add (shl x, N), x) in AArch64, into the DAGCombiner to have this optimization generic on all targets. However, running the LLVM Tests leads to 67 unexpected results. Am 19.09.2017 um 15:58 schrieb Sanjay Patel: > For the

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated