similar to: [LLVMdev] Undefined metadata

Hi, I am observing some incorrect behavior in basicaa, wherein two pointers that basicaa should determine to be MustAlias are ending up NoAlias - the other extreme :( I am blaming this on basicaa not handling inttoptr. Here is the relevant IR snippet. -------------------- %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr37 = add i32 %sunkaddr36, 16 %sunkaddr38 = inttoptr i32

Hi, I have the following IR code </snippet> %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 store %struct.myStruct* %0, %struct.myStruct** %next1, align 4, !tbaa !0 %2 = load %struct.myStruct** %prev, align 4, !tbaa ! </snippet> myStruct is

On Thu, Nov 8, 2012 at 6:53 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I am observing some incorrect behavior in basicaa, wherein two pointers that > basicaa should determine to be MustAlias are ending up NoAlias - the other > extreme :( > I am blaming this on basicaa not handling inttoptr. Here is the relevant IR > snippet. >

On 4/30/2014 5:24 PM, Craig Topper wrote: > Pranav, can you remove it? > Yes, I'll remove it. Pranav -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

BasicAA treats it conservatively if used on its own. It will return mayalias for the two pointers. TBAA operates based on the guarantee that pointers to different types cannot alias (think C's strict aliasing rules). Therein lies its power but also its danger, that is, nothing prevents the programmer to write code that violates these rules (That's why we have -fno-strict-aliasing). So

Hi, Scalar evolution seems to be wrapping around the trip count in the following loop. void add (int *restrict a, int *restrict b, int *restrict c) { char i; for (i = 0; i < 255; i++) a[i] = b[i] + c[i]; } When I run scalar evolution on the bit code, I get a backedge-taken count which is obviously wrong. $> cat loop.ll ; Function Attrs: nounwind define void @add(i32* noalias

On Thu, Oct 25, 2012 at 3:15 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Hi, > > I have the following IR code > > </snippet> > %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 > %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 > %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 > store %struct.myStruct*

On 4/30/2014 2:00 PM, Matthew Curtis wrote: > On 4/30/2014 9:01 AM, Krzysztof Parzyszek wrote: >> On 4/30/2014 8:45 AM, Rafael Espíndola wrote: >>> On 30 April 2014 00:52, Craig Topper <craig.topper at gmail.com> wrote: >>>> This function is marked virtual but doesn't override anything, >>>> doesn't have >>>> any overrides, and

Hi, I am defining Hexagons version of ReplaceNodeResults to change the a node of the type A: i8 = INTRINSIC_WO_CHAIN ... , ... , To B: SIGN_EXTEND (A) After returning from my function, the type legalizer calss ReplaceValuesUsesWith to replace the uses of A with B. Unfortunately, it replaces the use of A in the new node B too. So the node now is B: SIGN_EXTEND(B) , which is clearly bad and the

Hi Pranav, > In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, > I see this code > ------ > // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that > // BasicAliasAnalysis wins if they disagree. This is intended to help > // support "obvious" type-punning idioms. > PM.add(createTypeBasedAliasAnalysisPass()); >

Hi, This question relates to the undef flag in the context of sub-register def operands. 1) Firstly, the documentation (comments in the source code) says that in a sub-register def operand, the "IsUndef" flag refers to the part of the register that is not written. 2) Further, the documentation about readsReg() states that a sub-register def implicitly reads the other parts of the

On Thu, Sep 13, 2012 at 1:14 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Just adding to the clamor for FileChecks ability to pattern match > out-of-order (match for mere presence); Just in the last 2 weeks, I have > come across at least a couple instances when I was unable to add small unit > tests to the testsuite because of this deficiency in FileCheck. Also, I

Hi, I have a case that is causing me grief in the form of an assert. The prolog Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE instruction that looks like this (alongwith the Frame Index). This is for the Hexagon backend. ************************** fi#2: size=4, align=4, at location [SP-84] DBG_VALUE <fi#2>, 0, !"fooBar"; line no:299

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Pranav Bhandarkar > Sent: Thursday, April 26, 2012 5:24 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] MemRefs in a Load Instruction > > Hi, > > On the hexagon target, I have written a following combiner pattern. >

Hi Jakob, > New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 > are 32 bit virt. regs. > New_MI_2:: Vreg2 = COPY C:lo_sub_reg. > New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B > is a > 64 bit virt reg. I used this approach and it worked find until I hit, what I believe is, a bug in the register coalescer. When the register

> Can you explain why you were unable to add a small unit test to the testsuite? This is the case I have. ****** r3 = memb(r1+#1) r4 = memb(r1+ #0) .. .. { p0 = r3 /* Should almost never emit this. */ p1 = r4 /* Should almost never emit this. */ .. .. p0 = or(p1, p0) ***** The CHECK tags I have are ; CHECK: [[IntReg0:r[0-9]+]]

Hi, In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, I see this code ------ // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. PM.add(createTypeBasedAliasAnalysisPass()); PM.add(createBasicAliasAnalysisPass()); } ------ My

On Jul 5, 2012, at 6:01 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > Hi Jakob, > >> New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 >> are 32 bit virt. regs. >> New_MI_2:: Vreg2 = COPY C:lo_sub_reg. >> New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B >> is a >> 64 bit

Hi Jakob, Thanks for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation

Hi, On the hexagon target, I have written a following combiner pattern. ********************************************* def: Pat<(i64 (or (i64 (shl (i64 (extloadi32 (i32 (add IntRegs:$src1, s11_2ExtPred:$offset1)))), (i32 32))), (i64 (zextloadi32 ADDRriS11_2:$src2)))), (i64 (COMBINE_rr