similar to: [LLVMdev] ADDE on HW that doesn't have flags?

On Mon, Oct 27, 2008 at 10:11 AM, Daniel M Gessel <gessel at apple.com> wrote: > 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

Thanks - that solves both problems. In the future, HW may have built in ADDE support, but will likely still not have flags - it'll just read 3 registers and write two. Any thoughts there? Thanks, Dan On Oct 27, 2008, at 12:07 PM, Andrew Lenharth wrote: > On Mon, Oct 27, 2008 at 10:11 AM, Daniel M Gessel <gessel at apple.com> > wrote: >> The language I'm

On Mon, Oct 27, 2008 at 11:15 AM, Daniel M Gessel <gessel at apple.com> wrote: > Thanks - that solves both problems. > > In the future, HW may have built in ADDE support, but will likely > still not have flags - it'll just read 3 registers and write two. > > Any thoughts there? Yes. What I think should happen is flags need to be less of a hack. There are two cases,

Thanks very much for your help. I didn't quite understand how adde really uses flags in, say x86 or any of the other architectures I looked at. It seemed to declare it used EFLAGS, but little else: like how would you feed a zero in for the carry. Or I suppose you would have to start such a sequence off with an addc, and I happened to hit the adde (and it bailed) first (because the

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

Dear All, I am trying to custom lower 32-bit ISD::SHL and SHR in a backend for 6502 family CPUs. The particular subtarget has 16-bit registers at most, so a 32-bit result is not legal. Normally, if you mark this as "Legal" or "Expand", then it will expand the node into a more nodes as follows in an example: shl i32 %a , 2 => high_sdvalue = (or (shr %b, 14), (shl %c, 2) )

These opcodes have been deprecated about a year ago, but still in use in various backend. In https://reviews.llvm.org/D47422 I would like to change the behavior of the backend to not enable the use of these opcodes by default. The opcode remains usable by any backend that wish to use them, but that should limit the situation where newer backend just use them as they are enabled by default. This

I forgot to mention that I used EXTRACT_ELEMENT in my backend to get the high and low parts of an SDValue. On 10 Nov 2013, at 17:50, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation

I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation on the 2 8-bit subregs of that 16-bit register. That means the only practical solution for 32-bit shifts is to lower to a libcall but my situation for 16-bit shifts sounds similar to yours for 32-bit shifts. I

For targets where ADDCARRY and SUBCARRY are legal, would it make sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? Are there plans to deprecate UADDO/USUBO in favor of ADDCARRY/SUBCARRY? -Krzysztof On 5/30/2018 11:57 AM, Amaury Séchet via llvm-dev wrote: > These opcodes have been deprecated about a year ago, but still in use in > various backend. > > In

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

Legalizer will expand arithmetics using addc and adde. Is it not working for you? It works fine on x86, you can take a look how it's done. Evan On Sep 8, 2008, at 4:03 AM, Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out > the > magic. Here's

On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote: > For targets where ADDCARRY and SUBCARRY are legal, would it make sense > to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? SelectionDAG will never generate ADDC/ADDE on targets where they aren't legal.  Targets which custom-lower ADDCARRY generally also custom-lower UADDO; not sure what sort of expansion

Hi Steve, Thanks for confirming that EXTRACT_ELEMENT is something I can use. I had seen it in the generated DAGs but was unsure whether I was "allowed" to use it, if that's the right word. I checked up on it more and indeed the mainstream targets like ARM use that node type in custom lowering code, so that should solve that. Perhaps in the future I might submit a patch for

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

On 5/30/2018 1:16 PM, Friedman, Eli wrote: > On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote: >> For targets where ADDCARRY and SUBCARRY are legal, would it make sense >> to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? > > SelectionDAG will never generate ADDC/ADDE on targets where they aren't > legal.  Targets which custom-lower

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

Hi, I am working on a LLVM backend that has eight different branch registers. I am having a lot of trouble with implementing the following instructions: addcg $r0.1, $b0.0 = $r0.1, $r0.1, $b0.0 (r is a general purpose register and b is a 1 bit branch register) The branch register is used for carry in and carry out. I have noticed that this instruction is very closely related to the ADDE

Evan Cheng wrote: > Legalizer will expand arithmetics using addc and adde. Is it not > working for you? It works fine on x86, you can take a look how it's > done. > > Evan The x86 has a carry bit, my target doesn't. It's not clear to me how I would specify the use of a general purpose register to contain the calculated carry in the current adde/addc scheme.

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