similar to: [SDAG] Recovering pointer types

On 26 Dec 2016, at 14:58, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am wondering if there is a good/easy way to recover the original type of a pointer parameter in the SDAG. Here's the problem that I am dealing with: > > define <4 x i32> @test(i32* nocapture readonly %a) local_unnamed_addr #0 { > entry: > %0 = bitcast i32* %a to

David, thank you for the prompt response. I originally implemented this with a check of getAlignment(). However, both getAlignment() and getOriginalAlignment() on the <4 x i32> load return the stronger alignment (16) rather than the alignment that the i32* parameter would have (4). So I am a bit stuck in terms of how to verify the original alignment. On Mon, Dec 26, 2016 at 3:26 PM, David

Hello, I've hit an assertion in SelectionDAG where we try to merge 2 loads that have the same operands but their MMO flags differ. One is dereferenceable and one is not. I'm not sure what the underlying issue here is: 1) MDSDNode with the same operands should have the same flags set on their respective MMO. The fact the flags differ when the opcode,types,operands and address-space are

On 26 Dec 2016, at 15:49, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > David, thank you for the prompt response. > I originally implemented this with a check of getAlignment(). However, both getAlignment() and getOriginalAlignment() on the <4 x i32> load return the stronger alignment (16) rather than the alignment that the i32* parameter would have (4). > >

I have added new instructions to my target, unfortunately they are not being properly type legalized. The instructions I've added are a vector add, vector load and a vector store. Can anyone lend a hand on how to legalize them so that my target would be able to recognize them. Below is the output of llc with a -debug-only=isel. As you could see the output type for load, store, and add changes

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

I'm trying to figure out how to interpret DAG output that is shown below. If I were to draw it by hand, how would I do it? I tried to do it, but unfortunately I can't figure it out. I know there is a way to generate a graph, but I made some changes to my backend which hangs clang/llc. Would someone be kind enough to give a picture of what of a graph below? I'm sure once I see one I

Hi, SystemZ supports @llvm.ctlz.i64() natively with a single instruction (FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64. For some reason, this leads to unfolded additions of constants as shown below: This function: define i16 @fun(i16 %arg) {   %1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction

A few library calls are commutable by definition, for example multiplications. I defined them as LibCalls for my architecture. However, I found that arguments are always passed in the order they are generated by Clang thus missing possible optimisations. For example, the following IR code ; Function Attrs: minsize norecurse nounwind optsize readnone define dso_local i16 @multTest(i16 %a, i16

On Thu, Mar 17, 2016 at 2:41 PM, Rail Shafigulin <rail at esenciatech.com> wrote: > On Thu, Mar 17, 2016 at 10:10 AM, Rail Shafigulin <rail at esenciatech.com> > wrote: > >> On Wed, Mar 16, 2016 at 6:38 PM, Mehdi Amini <mehdi.amini at apple.com> >> wrote: >> >>> >>> On Mar 16, 2016, at 5:38 PM, Rail Shafigulin <rail at

> On Mar 18, 2016, at 12:52 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Mar 18, 2016, at 12:45 PM, Rail Shafigulin <rail at esenciatech.com <mailto:rail at esenciatech.com>> wrote: >> >> On Thu, Mar 17, 2016 at 2:41 PM, Rail Shafigulin <rail at esenciatech.com <mailto:rail at esenciatech.com>> wrote: >> On Thu,

Hi, I have a question on write.table: I have a data.frame called t7 as below: > dim(t7) [1] 14015184 6 > t7[1:5,] uci uce par line graphical.forms stems 1 0 0 0 0 active activ 2 0 0 0 0 policy polici 3 0 0 0 0 wc PC 4 0 0 0 0 eff elf 5 0 0 0 0 icn ICC I want to write the

I'm working on enhancing TableGen's type checking and it triggered with a problem in CellSPU's specification: XSHWv4i32: (set VECREG:v8i16:$rDest, (sext:v8i16 VECREG:v4i32:$rSrc)) It's complaining that v4i32 is not smaller than v8i16, which is true in the sense of vector bit size, and true in the sense of vector element size. To me, a sign extension from i32 to i16 makes no

Hi all, The attached LLVM assembly file fails to generate x86 code when compiled using llc. compilation command - ../llvm-build/bin/llc -filetype=asm -march=x86-64 -mcpu=core-avx2 ex4.ll The error message is, LLVM ERROR: Cannot select: t95: v8f32 = X86ISD::SUBV_BROADCAST t17 t17: v4f32,ch = load<LD16[%scevgep](tbaa=<0x4dbcd98>)> t0, t16, undef:i64 t16: i64 = add t2,

Hi, The ldN like intrinsics (including all the ld1xN, ldN, ldNlane, ldNr, stN, stNlane) can use any pointer types. The definition (in IntrinsicsAArch64.td) of such intrinsics use 'LLVMAnyPointerType', which means we can pass any pointer type to such intrinsics. E.g. I tried following case ld2.ll: define { <4 x i32>, <4 x i32> } @test(float* %ptr) { %vld2 = call {

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

Hi, I am having issues running a new backend that I created for a new architecture. I suspect these errors may have something to do with how I have the string setup in LLVMTargetMachine() below? Also - It would be great if someone could point me to a document that describes some of these error messages? For example what does t26 ..t4 mean? Thanks in advance for taking your valuable time to help

All, I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them. These sub-registers are special, they are only mentioned here: let CompositeIndices = [(sub_ss), (sub_sd)] in { def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; def

Is there any way to get it to delay this optimization where it goes from this: Initial selection DAG: BB#0 'bclr64:entry' SelectionDAG has 14 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 t6: i64 = sub t4, Constant:i64<1> t7: i64 = shl Constant:i64<1>, t6

Hi, I am trying to understand how vector type legalization works. In particular, I'm looking at i8 vector types on x86 (with sse42 features) v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets promoted to v4i32. Why doesn't v3i8 (or even v4i8) get widened to v16i8? Alternatively, v3i8 could be widened to v4i8 then