search for: gr0

...tion # Machine code for testBooleanNot(): <fi #-4> is 4 bytes fixed at location [SP-80] <fi #-3> is 4 bytes fixed at location [SP-76] <fi #-2> is 4 bytes fixed at location [SP-72] <fi #-1> is 4 bytes fixed at location [SP-68] entry (0x8065970, LLVM BB @0x805fde8): %gr0 = load <fi#-1> %gr1 = load <fi#-2> %gr2 = load <fi#-3> %gr3 = load <fi#-4> %gr4 = move 1 setcc %gr0, %gr4 if v< goto %disp(label entry.selecttrue) %gr0 = move 0 %gr0 = move %gr0 goto %disp(label entry.selectcont) entry.selecttrue (0x80659d0, LLVM BB @0x80639b0):...

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > I assume that the two unconditional gotos are just test code, right? If > > not, the second one is dead. > > Yes, in the final form there will be "iflt" instruction before the first goto, > making it conditional. Ah, ok :) > > > The code after "goto" is disturbing. It looks like spill code, but

Chris Lattner wrote: > On Tue, 8 Jun 2004, Vladimir Prus wrote: > > While adding support for branch instructions in my backend, I run into a > > trouble. The code to handle branches looks like: > > The machine code after instruction selection is: > > > > entry (0x8681458): > > %reg1024 = load <fi#-1> > > %reg1025 = load

...hine code for _Z3addii(). Code after register allocation # Machine code for _Z3addii(): <fi #-2> is 4 bytes fixed at location [SP-20] <fi #-1> is 4 bytes fixed at location [SP-16] <fi #0> is 4 bytes <fi #1> is 4 bytes <fi #2> is 4 bytes entry (0x8681458): %gr0 = load <fi#-1> %gr1 = load <fi#-2> setcc %gr0, %gr1 store <fi#0>, %gr0 store <fi#1>, %gr1 goto %disp(label then) goto %disp(label else) then (0x8681688): %gr0 = load <fi#1> %gr1 = load <fi#0> %gr0 = + %gr0, %gr1 %gr7 = move %gr0 return else (0x86815e...

...any parameters. The change log is just: * Target.td: Revamp the Register class, and allow the use of the RegisterGroup class to specify aliases directly in register definitions. and I could not find any discussions in the archives. Why the change was necessary? Writing: def gr0 : Register<"gr0">; def gr1 : Register<"gr1">; def gr2 : Register<"gr2">; def gr3 : Register<"gr3">; def gr4 : Register<"gr4">; is a bit boring and it's very easy to make a mistake. How the names are used?...

On Tue, 16 Nov 2004, Vladimir Prus wrote: > and I could not find any discussions in the archives. > > Why the change was necessary? Writing: > > def gr0 : Register<"gr0">; > def gr1 : Register<"gr1">; > def gr2 : Register<"gr2">; > def gr3 : Register<"gr3">; > def gr4 : Register<"gr4">; > > is a bit boring and it's very easy to make a mista...

...then) goto %disp(label else) then (0x8681688): %reg1026 = + %reg1025, %reg1024 %gr7 = move %reg1026 return .... which looks ok, but after register allocation and prolog/epilogue insertion, I get this: entry (0x8681458): ..... setcc %gr0, %gr1 goto %disp(label then) goto %disp(label else) %ar6 = + %ar6, 1 store %ar6, %gr0 %ar6 = - %ar6, 1 %ar6 = + %ar6, 2 store %ar6, %gr1 %ar6 = - %ar6, 2 The code after "goto" is disturbing. It looks like spill code, but it&...

Hello! Is there an (semi)automatic way to save registers used by a function? For example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For now I just emit huge prologue code to push them all to stack -- even if they are not modified at all. Is there a way to tell LLVM which registers must be stored, and have it automatically issue pushes/pops? I can live with current design, just wondering. - Volodya

...goto %disp(label else) I assume that the two unconditional gotos are just test code, right? If not, the second one is dead. > which looks ok, but after register allocation and prolog/epilogue insertion, I > get this: > > entry (0x8681458): > ..... > setcc %gr0, %gr1 > goto %disp(label then) > goto %disp(label else) > %ar6 = + %ar6, 1 > store %ar6, %gr0 > %ar6 = - %ar6, 1 > %ar6 = + %ar6, 2 > store %ar6, %gr1 > %ar6 = - %ar6, 2 > > The code after "goto"...

On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > Hello! > Is there an (semi)automatic way to save registers used by a function? For > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For now > I just emit huge prologue code to push them all to stack -- even if they are > not modified at all. > > Is there a way to tell LLVM which registers must be stored, and have it > automatically issue pushes/pops? I can live with current design, just > w...

Alkis Evlogimenos wrote: > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > Hello! > > Is there an (semi)automatic way to save registers used by a function? For > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > now I just emit huge prologue code to push them all to stack -- even if > > they are not modified at all. > > > > Is there a way to tell LLVM which registers must be stored, and have it > > automatically issue pushes/pops? I can live with current...

...09 at 05:26, Vladimir Prus wrote: > Alkis Evlogimenos wrote: > > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > > Hello! > > > Is there an (semi)automatic way to save registers used by a function? For > > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > > now I just emit huge prologue code to push them all to stack -- even if > > > they are not modified at all. > > > > > > Is there a way to tell LLVM which registers must be stored, and have it > > > automatically issue pushes/pops...

...(for the future) and one for fp64. fp32 aliases the > integer register set. fp64 aliases the fp32 register set, but not the > integer register set explicitly. I thought that aliases are transitive? > Or do I have to mention all aliases explicitly, e.g. for %d0 I need to > say [%s0,%s1,%GR0,%GR1]? Depending on how you defined the aliases, they aren't necessarily transitive. I'd like at the <yourtarget>GenRegisterInfo.inc file, and see what it lists as the aliases for each reg. > But a more interesting question is this: The scheme above assumes that > there is...

...r sets. One for fp32 (for the future) and one for fp64. fp32 aliases the integer register set. fp64 aliases the fp32 register set, but not the integer register set explicitly. I thought that aliases are transitive? Or do I have to mention all aliases explicitly, e.g. for %d0 I need to say [%s0,%s1,%GR0,%GR1]? But a more interesting question is this: The scheme above assumes that there is a "hardwired" mapping between FP registers and concerete pairs of integer registers. In many cases this is enough, since the emulated operations indeed expect parameters on predefined pairs of 32bit in...

On Mon, 9 Oct 2006, Roman Levenstein wrote: > I'm now ready to implement the FP support for my embedded target. cool. > My target supports only f64 at the moment. > Question: How can I tell LLVM that float is the same as double on my > target? May be by assigning the same register class to both MVT::f32 > and MVT::f64? Just don't assign a register class for the f32 type.

Hi, I'm now ready to implement the FP support for my embedded target. My target supports only f64 at the moment. Question: How can I tell LLVM that float is the same as double on my target? May be by assigning the same register class to both MVT::f32 and MVT::f64? But FP is supported only in the emulated mode, because the target does not have any hardware support for FP. Therefore each FP

...aliases > the > > integer register set. fp64 aliases the fp32 register set, but not > the > > integer register set explicitly. I thought that aliases are > transitive? > > Or do I have to mention all aliases explicitly, e.g. for %d0 I need > to > > say [%s0,%s1,%GR0,%GR1]? > > Depending on how you defined the aliases, they aren't necessarily > transitive. I'd like at the <yourtarget>GenRegisterInfo.inc file, > and see > what it lists as the aliases for each reg. Done. And I looked into the tblgen code. Tarnsitivity is not ensu...