search for: 2xi32

..." f64 to 2x i32. I tried to implement it, but I still have some troubles with that. In my understanding, the code in TargetLowering.cpp and also in SelectioNDAGISel.cpp should be altered. I tried for example to modify the computeRegisterProperties to tell that f64 is actually represented as 2xi32. I also added some code into the function FunctionLoweringInfo::CreateRegForValue for allocating this pair of i32 regs for f64 values. But it does not seem to help. >From what I can see, the problem is that emitNode() still looks at the machine instruction descriptions. And since I still have s...

...> I tried to implement it, but I still have some troubles with that. > In my understanding, the code in TargetLowering.cpp and also in > SelectioNDAGISel.cpp should be altered. I tried for example to modify > the computeRegisterProperties to tell that f64 is actually represented > as 2xi32. Good, this is the first step. Your goal is to get TLI.getTypeAction(MVT::f64) to return 'expand' and to get TLI.getTypeToTransformTo(f64) to return i32. > I also added some code into the function > FunctionLoweringInfo::CreateRegForValue for allocating this pair of i32 > regs...

Hi Richard, > In LLVM 2.9 and LLVM 3.0, our front-end generates: > > @__shuffle_2f32_2u32 = alias weak <2 x i32> (<2 x i32>, <2 x i32>)* @4 > > And the calls, before linking, look like: > > %call9 = call <2 x float> @__shuffle_2f32_2u32(<2 x float> %tmp7, <2 x i32> > %tmp8) nounwind I don't see how this is possible - it should be

...which register is killed? Would it be legal for operands 0 and 1 to refer to different registers? 128B %R3<def> = KILL %R3, %R3_1<imp-use>, %R3_23<imp-use> (In my out-of-tree target, %R3 is a <4xi32> register, %R3_1 is an i32 sub-register of %R3, and %R3_23 is a <2xi32> sub-register of %R3). Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/0267f9a4/attachment.html>

We use alias extensively in our library to support OpenCL generating code for both our CPUs and GPUs. During the transition to LLVM 3.0 with the new type system, we're seeing two problems. Both involve type conversions occurring across an alias. In one case, one of the types is pointer to an opaque type, and ends up creating an assert in the verifier where it is checking that argument types

On Tue, 10 Oct 2006, Roman Levenstein wrote: >> I don't understand. If you are writing out the .o file directly, you >> already know how to encode calls... can't you just encode it as the >> right sort of call? > > Yes, sure. I simply overlooked it, because it is too simple and obvious > ;) I was thinking about doing it at a higher level, but this can be >

...but I still have some troubles with that. > > In my understanding, the code in TargetLowering.cpp and also in > > SelectioNDAGISel.cpp should be altered. I tried for example to > modify > > the computeRegisterProperties to tell that f64 is actually > represented > > as 2xi32. > > Good, this is the first step. Your goal is to get > TLI.getTypeAction(MVT::f64) to return 'expand' and to get > TLI.getTypeToTransformTo(f64) to return i32. After I sent a mail to the mailing list, I figured out that I need to do this, so I added exactly what you descr...

> On Tue, 10 Oct 2006, Roman Levenstein wrote: > >>> such a call instruction? > >> > >> Why not just make the asm string be "call __fsub64"? > > > > Well, of course it would be the best solution. But the interesting > part > > is that I need to generate the machine code directly because for > > different reasons use of a system