similar to: [LLVMdev] Undoing DAG Combiner patterns

On Thu, May 16, 2013 at 02:03:14AM +0000, Martin Filteau wrote: > Hi all, > > It's the first LLVM backend we do for our asynchronous DSP. So, I apologize if this is a trivial question! > > The target-independent DAG combiner performs the following transformation: > > sub n, c -> add n, -c > It looks to me like this transformation would happen

A better way to handle this is to a td pattern to match "add n, -c" to a subtraction. I believe several targets do something similar to this. Evan On May 16, 2013, at 7:12 AM, Tom Stellard <tom at stellard.net> wrote: > On Thu, May 16, 2013 at 02:03:14AM +0000, Martin Filteau wrote: >> Hi all, >> >> It's the first LLVM backend we do for our asynchronous

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

Hi, I see that for different targets in classes which inherits from TargetLowering there are implemented both methods: LowerOperation and ReplaceNodeResults What decides that for one given ISD we have to add handling in LowerOperation and for other in ReplaceNodeResults, when for both SetOperationAction is configured to be Custom? Is it related with number of results of given operation and

On 24/08/2009, at 01.19, Stripf, Timo wrote: > > I had also a lot of problems to get the i1 operations working. E.g. > I had to override the getSetCCResultType to get is working and for > ADDE/ADDC the i1 target registers are hardcoded. What is your SetCCResultType now? Can you compile the CodeGen/Blackfin/basic-i1.ll test case? I never got that one working with legal i1. The

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

Hi, On 01/22/2016 05:02 PM, Tom Stellard wrote: > On Fri, Jan 22, 2016 at 01:58:49PM +0100, Mikael Holmén via llvm-dev wrote: >> Hi, >> >> I'm a litle bit puzzled by the TargetLowering::LowerOperation function, >> and what different callers of this function assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best

Hi Jakob, I forget to mention that I'm working atm on the old 2.5 release code base and not on the svn. So I don't know if the problem still exists. I'm going to test it now. > The Blackfin DSP can do simple i1 operations with the CC flag and > status bits. Initially I also marked i1 as a legal type, but it caused > a lot of problems. Now I pretend that the CC register

On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi again, > > Kind people on #llvm helped me to utilize bugpoint to reduce the > previously submitted test case. For record, it code be done with the > following command: > > $ bugpoint -llc-safe test.ll > > The resulting IR is attached, and it is crashing in the same way. Is >

Hi Dmitry, > So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one > should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); > and implement it in NVPTXTargetLowering::LowerOperation. > > But this issue makes a good point about the code efficiency: I suspect > such expansion will be very ugly in terms of performance. Probably we > can do much better if

On 23/08/2009, at 18.42, Stripf, Timo wrote: > Hi all, > > i’m writing an back-end for a new research processor architecture > and have problems with the DAG Combiner. The processor architecture > supports i1 and i32 registers. 1-bit registers are mainly used as > comparison result but basic operations like OR are not possible > between i1 registers. So I wrote custom

Hi all, i'm writing an back-end for a new research processor architecture and have problems with the DAG Combiner. The processor architecture supports i1 and i32 registers. 1-bit registers are mainly used as comparison result but basic operations like OR are not possible between i1 registers. So I wrote custom lowering for i1 OR operations and replaced it by (trunc (or (aext x), (aext

The language I'm targeting doesn't have flags; I'd like to implement ADDE as a macro or psuedo-instruction that takes 3 parameters and returns 2. In my InstrInfo.td file, tablegen complains if I try to define multiple return values; adde is defined in TargetSelectionDAG.td to be a binary op that takes an extra flag in and sends an extra flag out. I tried to custom lower ADDE

Hi Dmitry, >> did you declare i1 to be an illegal type? > > No. How? I think it will be considered illegal if you don't add it to any register class. Ciao, Duncan. > > 2012/6/30 Duncan Sands <baldrick at free.fr>: >> Hi Dmitry, >>> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one >>> should probably do

Okay, few issues here: First, i1 is used in the NVPTX back-end to map to the predicate (.pred) type. We definitely do not want to declare this type as illegal. The real issue is lack of complete support for this type. The PTX language places restrictions on what can be done with .pred registers, and it looks like the failure is here: kernelgen_hostcall.exit228: ; preds =

Thanks, for insight, Eli, So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); and implement it in NVPTXTargetLowering::LowerOperation. But this issue makes a good point about the code efficiency: I suspect such expansion will be very ugly in terms of performance. Probably we can do much better if bool would use

Salut Ivan, On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > Le 25/05/2012 18:54, Sebastian Pop a écrit : >> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org>  wrote: >>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov>  wrote: >>>> Sebastian,

Hi Renato, > * Have some call-back mechanism, possibly upon a flag > (HasSpecialDivRemLowering), and update the remainder result If you setOperationAction on SDIVREM and UDIVREM to Custom you can expand the rtlib call appropriately yourself. There's precedent for sincos on Darwin systems (both ARM and x86) and in AArch64 for basically every operation on fp128. Cheers. Tim.

I converted now my back-end with legal i1 lowering to the 2.6 branch and my original problem with the DAG combiner didn't occur any more and seems to be fixed. setOperationAction(ISD::OR, MVT::i1, Promote) also works fine for logical operations. > What is your SetCCResultType now? I changed SetCCResultType to return MVT::i1 type. > Can you compile the CodeGen/Blackfin/basic-i1.ll

Hi, I'm a litle bit puzzled by the TargetLowering::LowerOperation function, and what different callers of this function assumes about the returned value. In several places it seems like it is assumed that LowerOperation can return three kinds of values: * Something completely new. * SDValue() * The same SDValue as LowerOperation was called on. However in some places, e.g. in