search for: cr6

...elLowering.cpp, LowerCALL). right. > I need some help on how to insert the creqv instruction in the calling > sequence. The basic approach you want to take: 1. Introduce a new target-specific dag node to represent "SETCR", which takes a single register operand (in this case, CR6). 2. At call lowering time, flag this into the call sequence. 3. At ISel time, turn this into creq reg,reg,reg > After this is implemented, I will be able to send a patch for linux/ppc > support. Nice. This will also resolve http://llvm.org/PR1064 > I also need to know what is your pr...

Hi all, llvm newbie here. I'm trying to branch based on a vector compare. I've found a slow way (below) which goes through memory. Is there some idiom I'm missing so that it would use for instance movmsk for SSE or vcmpgt & cr6 for altivec? Or do I need to resort to calling the intrinsic directly? Thanks, Stephen. %16 = fcmp ogt <4 x float> %15, %cr %17 = extractelement <4 x i1> %16, i32 0 %18 = extractelement <4 x i1> %16, i32 1 %19 = extractelement <4 x i1> %16, i32 2 %20 = extracte...

Hi all, I'm currently implementing a linux/ppc target in llvm. The abis between Darwin/ppc and linux/ppc are different and I'm running into problems with vararg calls. Before a variadic method is called, an extra instruction must be executed (which is creqv 6, 6, 6). This instruction is not necessary in Darwin/ppc. I looked into the PowerPC target implementation and the code generation

...ber the non-callee saved registers... Defs = [{ static const unsigned Defs_ELF[] = {R0,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11,R12, F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10, V0,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, LR,CTR, CR0,CR1,CR5,CR6,CR7} static const unsigned Defs_Macho[] = {R0,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11,R12, F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13, V0,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, LR,CTR, CR0,CR1,CR5,CR6,CR7} GPRClass::iterator...

Hi Stephen, > Hi all, llvm newbie here. welcome! > I'm trying to branch based on a vector compare. I've found a slow way (below) > which goes through memory. Is there some idiom I'm missing so that it would use > for instance movmsk for SSE or vcmpgt & cr6 for altivec? I don't think you are missing anything: LLVM IR has no support for horizontal operations like or'ing the elements of a vector of boolean together. The code generators do try to recognize a few idioms and synthesize horizontal operations from them, but I think only addition is...

Is there any reason why we can't generate HWEncoding based decoders for registers for mc disassemblers? This is a concept patch to explore wether it'd work, and for my target, it does the right thing. I have one case where I have to shift a field over 2 bits, but I handle that in the glue. If I had a HWEncoding encoding on a per register class basis, I could have made it work without

...if I create a new language and a new ABI for my >> language then I can expect to need to teach the backend about my new >> ABI. > > And so the backend has to be taught about the language. Only if that's what the ABI says. If my hypothetical ABI says that in a Z-context, the CR6 register controls whether floating point values are passed in registers or in memory, then the ABI-note says whether we're in a Z-context or not. To me, it is > about conveying the necessary information in a more portable way so the > mapping code only has to be written once. Makin...

...... > Defs = [{ > > > static const unsigned Defs_ELF[] = > {R0,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11,R12, > F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10, > > V0,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, > LR,CTR, > CR0,CR1,CR5,CR6,CR7} > > static const unsigned Defs_Macho[] = > {R0,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11,R12, > F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13, > > V0,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, > LR,CTR, > CR0,CR1,CR5,CR6,CR...

> > which goes through memory. Is there some idiom I'm missing so that it would use > > for instance movmsk for SSE or vcmpgt & cr6 for altivec? > > I don't think you are missing anything: LLVM IR has no support for horizontal > operations like or'ing the elements of a vector of boolean together. The code > generators do try to recognize a few idioms and synthesize horizontal > operations from them, but...

...d to. That could get tricky, as you'll effectively be fibbing to the register allocator. ARM uses quite a lot of late expanded pseudo-instructions, for example, though generally not w/ branching involved, so the regalloc implications are more easily modeled. >From the context, I gather that CR6 changes state dynamically over the course of a program's execution? It's not a compile time determinable thing? If it were compile time, you could deal with this as a different calling convention instead, which changes which regs are call clobbered vs. call preserved. Sounds like this is mo...

On Fri, 2 Feb 2007, Nicolas Geoffray wrote: > I have almost completed the implementation of a linux/ppc backend in llvm. Cool! > There were a few things to modify in > lib/Target/PowerPC with a lot of "if (!isDarwin)". Some meta comments: 1. Please don't change PPC -> llvmPPC. I assume that you did this because PPC is a #define in some system header. Please

...ike this from lib/Target/PowerPC/Disassembler/PPCDisassembler.cpp: > > // FIXME: These can be generated by TableGen from the existing register > // encoding values! > > static const unsigned CRRegs[] = { > PPC::CR0, PPC::CR1, PPC::CR2, PPC::CR3, > PPC::CR4, PPC::CR5, PPC::CR6, PPC::CR7 > }; Yeah, my code does this for free: extern const uint16_t PPCRegDecodingTable_CRRC[] = { /* [0] = */ PPC::CR0, /* [1] = */ PPC::CR1, /* [2] = */ PPC::CR2, /* [3] = */ PPC::CR3, /* [4] = */ PPC::CR4, /* [5] = */ PPC::CR5, /* [6] = */ PPC::CR6, /* [7] = */ PPC::CR7,...

Hi everyone, I have almost completed the implementation of a linux/ppc backend in llvm. There were a few things to modify in lib/Target/PowerPC with a lot of "if (!isDarwin)". There are some places where I need help before saying the port is complete. I attached the diff file as a reference 1) In order to generate a creqv instruction before a vararg call, I created a new

Nick Lewycky <nicholas at mxc.ca> writes: > Why should the backends know about the frontend language? It seems > sensible to me that if I create a new language and a new ABI for my > language then I can expect to need to teach the backend about my new > ABI. And so the backend has to be taught about the language. To me, it is about conveying the necessary information in a more

Am 04.09.2012 00:08, schrieb Stephen: >>> which goes through memory. Is there some idiom I'm missing so that it would > use >>> for instance movmsk for SSE or vcmpgt & cr6 for altivec? >> >> I don't think you are missing anything: LLVM IR has no support for horizontal >> operations like or'ing the elements of a vector of boolean together. The code >> generators do try to recognize a few idioms and synthesize horizontal >> operat...

Jim, Thanks! Might it be possible to do this another way? For example, could I insert some special pseudo-instructions and then turn them into branches later on? -Hal On Thu, 10 May 2012 11:39:10 -0700 Jim Grosbach <grosbach at apple.com> wrote: > Hi Hal, > > For lowering code that requires inserting branches, you need to use a > custom inserter, yes. Theoretically, that

David A. Greene wrote: > Duncan Sands<baldrick at free.fr> writes: > >>> Yep. There are lots of corner cases that the frontend MUST handle >>> because LLVM does not have the necessary infrastructure. >> >> I think it's more like: because LLVM doesn't have the necessary information. > > True. > >> Due to LLVM using structural

Hi Hal, For lowering code that requires inserting branches, you need to use a custom inserter, yes. Theoretically, that does indeed sound like what you want to do here. It's complicated by the general structure of argument passing, though. In particular, there's lots of assumptions about the call sequence stuff. I don't know if things are smart enough (EH in particular worries me) to

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See