similar to: [LLVMdev] ADDE to use branch registers

Way back on Wed Dec 14, 2005, Tzu-Chien Chiu wrote: > To write a compiler for Microsoft Direct3D shaders from our hardware, > I have a program which translates the Direct3D shader assembly to LLVM > assembly. I added several intrinsics for this purpose. > It's a vector ISA and has some special instructions like: > * rcp (reciprocal) > ... > These operations are very

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

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

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 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

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

On 5/30/2018 11:28 AM, Krzysztof Parzyszek wrote: > 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

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

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.

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 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 #

Why can't I custom lower ADDE operation for legal types? Our target does not have an add with carry instruction. We check the carry bit in status register and add 1 to the result if it is set. -Sanjiv

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

Any idea how to handle "adde" nodes for processors that do not have an "add with carry" instruction? In our case, we rely on "carry test" and "increment" instrunctions. Any reference to a similiar existing LLVM target will be helpful.. TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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,

Hi List- I''m brand new to xen but an old hand with Linux. With a fresh, clean, Gentoo installation on this box, I''m attempting to install xen using the gentoo-standard: emerge xen but the process is failing with an error that''s very similar to one reported by another user (A Streetcar Named: see

I made a patch that depending of gcc flavor add -no-pie or -nopie on libutil and dos Makefile. This fix fatal error like this sha1hash.c: In function `SHA1Transform': ../include/netinet/in.h:24: error: can't find a register in class `BREG' while reloading `asm' ../include/netinet/in.h:24: error: can't find a register in class `BREG' while reloading `asm'

On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote: > 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

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