similar to: [LLVMdev] [global-isel] ABI lowering clarifications

I have the following selection DAG: SelectionDAG has 9 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0, t2, undef:i64 t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16 t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15

On 9 Aug 2013, at 00:18, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I am hoping that this proposal will generate a lot of feedback, and there are many different topics to discuss. When replying to this email, please change the subject header to something more specific, but keep the [global-isel] tag. Subject changed, but I'm not sure if helps... Overall, I really like this

I am hoping that this proposal will generate a lot of feedback, and there are many different topics to discuss. When replying to this email, please change the subject header to something more specific, but keep the [global-isel] tag. Thanks, /jakob Proposal for a Global Instruction Selector It is becoming evident that we need a replacement for the SelectionDAG-based instruction selector. This

Hi, Compiling the simple following function with llv (LLVM 2.8) : define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) { %res = select <4 x i1> <i1 true, i1 false, i1 true, i1 true>, <4 x i32> %a, <4 x i32> %b ; ret <4 x i32> %res } gives : UNREACHABLE executed! 0 llc 0x0000000100927422 std::_Rb_tree<llvm::sys::Path,

Hi, Compiling the simple following function with llv (LLVM 2.8) : define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) { %res = select <4 x i1> <i1 true, i1 false, i1 true, i1 true>, <4 x i32> %a, <4 x i32> %b ; ret <4 x i32> %res } gives : UNREACHABLE executed! 0 llc 0x0000000100927422 std::_Rb_tree<llvm::sys::Path,

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

Dan Gohman wrote: > Hello, > > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets,

Hello, Attached is a patch which significantly reworks how calls, incoming arguments, and outgoing return values are lowered. It's a major change, affecting all targets, so I'm looking for feedback on the approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, and to facilitate future refactoring and feature work.

Duncan, I had a few thoughts regarding our short discussion yesterday. I am not sure how we can lower SEXT into the vpmovsx family of instructions. I propose the following strategy for the ZEXT and ANYEXT family of functions. At first, we let the Type Legalizer/VectorOpLegalizer scalarize the code. Next, we allow the dag-combiner to convert the BUILD_VECTOR node into a shuffle. This is

Hi, A bit more information. I believe my problem lies with the fact that the load is left as 'anyext from i8'. On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2? BB#1: 0x268c1b0: i32 = Register %vreg1 [ID=3] 0x2689d80:

Hi, I am receiving an LLVM Error from a custom 16-bit backend I am creating. I am having trouble understanding the error/problem and how to go about solving it. The error is: LLVM ERROR: Cannot select: t29: i32,ch = load<LD2[%x.addr], anyext from i16> t14, FrameIndex:i16<0>, undef:i16 t7: i16 = FrameIndex<0> t9: i16 = undef In function: mul_add Can anyone provide any

This sounds great! I've been bitten in the past by trying to use a single class for multiple types. Would it make sense to extend this to all DAG patterns? If I have an instruction def: def ANDN64 : MyInst<(outs Reg64:$d), (ins Reg64:$a, Reg64:$b), "and.64 $d, $a, $b", [(set Reg64:$d, (and (not (Reg64:$a, Reg64:$b))))]>; would I now be able to write: def ANDN64 :

Hello! Is there a way to tell LLVM how to emulate an instruction with multiple others? Specifically, in our processor, there is no instruction for adding two i64s; it has to be done like this dst_high32:dst_low32 = src1_low32 + src2_low32 (unsigned add; dst_high might contain the overflow bit) dst_high32 = dst_high32 + src1_high32 dst_high32 = dst_high32 + src2_high32 I tried it with

Hi Chandler, all, Why aren't the vector [zs]extloads introduced by SSE4.1/AVX2 declared legal? Is it a simple oversight, or did I miss a deeper reason? While cleaning up PMOV*X patterns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0

Hello, I am new to LLVM and doing some experiment with 3.2 on Ada code. Can anyone help me on the following error message? Thanks, ZY LLVM ERROR: Cannot select: 0xa7a0bf0: f32 = truncate 0xa7a5ea8 [ID=24] 0xa7a5ea8: i32 = X86ISD::SHLD 0xa790280, 0xa790390, 0xa76e088 [ID=22] 0xa790280: i32,ch = load 0xa7386a0, 0xa7a68d8, 0xa7a5628<LD1[%1482+4], anyext from i8> [ID=19]

Hi, it seems like SelectionDAGBuilder expects returning of vectors (structures/arrays) to be lowered in either of the two ways: 1. Flatten the complex data types to simple data types, and return them using registers (done by TargetLowering::LowerCallTo) 2. sret demotion: return the address of the complex data type via a stack pointer Is there an option to do sret demotion via a register? if yes,

Fast-isel is not equipped in general to deal with non legal types. It would seem that an llvm assembler pass run after clang but before llvm could do the lowering though. Any thoughts? Reed

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

Hi Nadav, > I had a few thoughts regarding our short discussion yesterday. > > I am not sure how we can lower SEXT into the vpmovsx family of instructions. I propose the following strategy for the ZEXT and ANYEXT family of functions. what I would like to understand first is why there are any vector xEXT nodes at all! As I tried to explain on IRC, I don't think you ever get these

On Apr 23, 2009, at 8:09 PM, Dan Gohman wrote: > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major > change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary