similar to: [LLVMdev] Target without registers

On Aug 6, 2008, at 3:54 AM, Sanjiv.Gupta at microchip.com wrote: > Pointer size on our target is 16-bits, and we have two 16-bit > registers that can be used only to hold pointers (indirect addresses). > > All operations on the target are 8-bit operations, so it takes two 8- > bit loads to load these pointer registers. > > We want LLVM to automatically expand all types to

Here's an example piece of code to show you what I'm trying to do (on llvm 3.1): class ArithLogicR<bits<6> op, bits<6> func, string instr_asm, SDNode OpNode, InstrItinClass itin, RegisterClass RC, bit isComm = 0>: FR<op, func, (outs RC:$rd), (ins RC:$rs, RC:$rt), !strconcat("+$rd=$rs ",!strconcat(instr_asm, " $rt")),

Pointer size on our target is 16-bits, and we have two 16-bit registers that can be used only to hold pointers (indirect addresses). All operations on the target are 8-bit operations, so it takes two 8-bit loads to load these pointer registers. We want LLVM to automatically expand all types to 8-bit values. The problem is that LLVM does not expand GlobalAddresses, which are 16-bit

Fabian, We have a very similar setup with the AMDIL backend(some operations support 64bit some don't). What we do is we enable MVT::i64, set legal to all operands that are legal and then set everything else to expand. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday,

> On Feb 26, 2016, at 1:54 PM, Matthias Braun <mbraun at apple.com> wrote: > > Let's try this again after some longer offline discussions: > > = Reserved Registers = > The primary use of reserved registers is to hold values required by runtime conventions. Typical examples are the stack pointer, frame pointer maybe TLS base address, GOT address ... > Zero registers

Hi LLVM-Folks, at our department we have an in-house developed back-end for the TriCore processor and we want to upgrade it to LLVM 3.1. However, we have some troubles regarding some instructions that work on 64bit registers: The TriCore processor has 16 32bit registers that can be paired to form 64bit registers. Except a few instructions all work on 32bit registers, thus the TriCore processor

Let's try this again after some longer offline discussions: = Reserved Registers = The primary use of reserved registers is to hold values required by runtime conventions. Typical examples are the stack pointer, frame pointer maybe TLS base address, GOT address ... Zero registers and program counters are an odd special case for which we may be able to provide looser rules. == Rules == 1)

Well, the stack pointer be a single byte, so pushing things on there doesn't work terribly well. Assuming I pass by reference, that's 128 values absolutely total before it wraps around and silently clobbers itself. It means single byte values will be incredibly inefficient... Tricky stuff. I'm lucky on the C64 since it's rare to exit back to the kernel with machine language apps

this is not an important question, but I wonder why lm returns an error, and whether this can be shut off. it would seem to me that returning NA's would make more sense in some cases---after all, the problem is clearly that coefficients cannot be computed. I know that I can trap the lm.fit() error---although I have always found this to be quite inconvenient---and this is easy if I have only

Author: danice Repository: /hg/zfs-crypto/gate Revision: 23a634d2405ff5c1e9e1ecf200708d8159060505 Log message: 6364698 Add /etc/system tunable support for XMITS'' UPPER_RTRY counter registers Files: update: usr/src/uts/sun4u/io/pci/pci_space.c update: usr/src/uts/sun4u/io/pci/pcisch.c update: usr/src/uts/sun4u/sys/pci/pci_pbm.h update: usr/src/uts/sun4u/sys/pci/pci_space.h update:

> > I don't think there is code in Legalizer to expand GlobalAddress. But you > can custom lower it. X86 custom lower GlobalAddress nodes for a different > reason. > > Evan > Hmmm...That means we have to make i16 as a legal type (since GlobalAddresses are 16-bits) and custom lower all 16-bit operations to 8-bit operations. I was thinking to take advantage of the

/// Optimizations after all the reg selections and spills are done. void InlineSpiller::postOptimization() { HSpiller.hoistAllSpills(); } Seems a problematic function to me, as hoistAllSpills() uses TII.storeRegToStackSlot() to insert new spills. The problem is, TII.storeRegToStackSlot is allowed to create new virtual registers, which can not be allocated a range as this whole thing is called

> On Feb 25, 2016, at 9:24 PM, Andrew Trick <atrick at apple.com> wrote: > > >> On Feb 25, 2016, at 6:14 PM, Matthias Braun <mbraun at apple.com> wrote: >> >> Lately I have had a few discussions of what it means for a register to be unallocatable or reserved. As this comes up every now and again and I often struggled answering such questions I decided to

Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and

> On Feb 25, 2016, at 6:14 PM, Matthias Braun <mbraun at apple.com> wrote: > > Lately I have had a few discussions of what it means for a register to be unallocatable or reserved. As this comes up every now and again and I often struggled answering such questions I decided to write down some definite rules and codify the current usage and assumptions. I plan to put the rules below

Hi Matthias, This pretty much matches my memory. I think that the rules are a bit ad hoc and not followed to the letter everywhere. It would be good to codify something concrete. I thought that I added some way of distinguishing between constant registers and other reserved registers but I can’t find it now. We do some register coalescing that is not consistent with your rules here: If a virtual

Sorry, I'm not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan

And now I've found the elusive bug in show.error.locations = TRUE as well, and posted a patch for that too. Back to the original topic of this thread: I think most users should routinely use options(show.error.locations = TRUE) e.g. in their .Rprofile. That will often speed up bug fixes, especially if my patch is incorporated. Duncan Murdoch On 2025-01-20 5:56 p.m., Duncan Murdoch

There is MachineRegisterInfo::isConstantPhysReg(), in the current implementation this just returns true if it cannot find any def operand for the register (or on of its aliases). I think we also write to zero registers at times and then this function would return false... For this to work reliably targets would need to provide the constant information explicitely. For the "writing to them

I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On