similar to: [LLVMdev] fields in structure re-arranged for alignment?

Hi, We've seen a similar case recently, where BasicAA returns PartialAlias for the access of two different fields of a structure. We noticed this since Lint complained about it when checking for aliasing beteen "noalias" attributed parameters: opt -S -lint ./alias.ll gave Unusual: noalias argument aliases another argument on the (silly) function: %rec7 = type { i16, i16, i16

    Thank you Kevin!!!    If I use fptrunc and bitcast realise NEON vcvtt ( I can sure, "fptrunc  double %tmp to float" is right, but "fptrunc float %tmp to half" is wrong). My target platform is MIPS.  The command as following: NEON:            vcvtt.f16.f32 s2, s0 llvm Code: %Vt_2 = load float* %VFP_s0, align 4 %Vt3_1 = fptrunc float %Vt_2 to half %Vt4_1 = bitcast half

Hi, I'm seeing a bug in the AVR backend that seems to be caused by LLVM thinking things will be aligned to 8 bytes whereas they are unaligned. Specifically, MF->getDataLayout().getPrefTypeAlignment(Ty) returns 8 for the following two types: %opt = type { i8, [0 x i8], [3 x i8] } %Machine = type { i16, [0 x i8], i16, [0 x i8], [16 x i8], [0 x i8] } The target datalayout specifies that

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

Hi! I followed the discussion on structure types with the example struct I { int a; char b; }; struct J : I { char c; }; Dave said that this translates to %I = type { i32, i8, i16 } %J = type { %I, i8, i16 } because the frontend has to communicate the ABI to llvm since llvm is language agnostic. What I really wonder is why it isn't %I = type { i32, i8 } %J = type { %I, i16, i8

Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: > struct I { > int a; > char b; > }; > > struct J : I { > char c; > }; > > Dave said that this translates to > > %I = type { i32, i8, i16 } > %J = type { %I, i8, i16 } It translates to that in OUR compiler. It's not the only answer. > because the frontend has to communicate the ABI to

>> What I really wonder is why it isn't >> >> %I = type { i32, i8 } >> %J = type { %I, i16, i8 } >> >> because llvm at least knows alignment rules by >> >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16... >> >> Therefore llvm has no other choice than assigning %I a size of 8 >> since an array may consist of %I

Hi, I would like some help regarding the LSR pass. It seems that it likes to duplicate address calculations as in the case above, which is highly undesirable on my target. I wonder if there is any way to tell LSR to not duplicate the code in cases like this? Or could I perhaps run CSE after LSR again? What is the logic behind this transformation? It seems that a LSR pass should not insert a

Hi, On 03/30/2016 11:15 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On my out-of-tree target I have an intrinsic >> >> def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], >> [llvm_i16_ty, llvm_i16_ty], >>

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is

Without the patch is also returns the wrong answer for all of these, it just doesn't cause LICM to promote because it returns PartialAlias (which is still wrong). We return may-alias instead, and now suddenly it's happy to promote them. The broken noalias results exist both before and after my patch: ===== Alias Analysis Evaluator Report ===== 521 Total Alias Queries Performed

I have written test.ll as below and ran 'opt' on it as " opt -std-compile-opts test.ll -S -o -" . But the output shows that there is code motion around the barrier intrinsics. test.ll ------- ; ModuleID = 'test.bc' define void @test(i16* %I_0, i16* %I_1, i16* %I_2, i16* %I_3, i16* %O_0) { entry: %T_0 = load volatile i16* %I_0 %T_1 = load volatile i16* %I_1 %T_2 =

On Mon, 22 May 2017, Dr. ERDI Gergo wrote: > Actually, tracking down the sequence of function calls, it turns out that '8' > is ultimately coming from the following call in DataLayout::getAlignment: > > getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); > > this seems to return 8 with the following datalayout string: > >

No, i mean the actual store instruction looks like "store i16 %conv22, i16* getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1" Not that the pointer operand comes from a GEP, but it is a constantexpr, whose opcode is GEP. It sucks that there is such a complex thing to be handled as a store operand directly , but such is life ... CFL-AA *should* treat this

Hi All, Using clang+llvm at head, I noticed a weird behaviour with the following reduced testcase : $ cat test.c #include <stdint.h> struct R { uint16_t a; uint16_t b; }; volatile struct R * const addr = (volatile struct R *) 416; void test(uint16_t a) { struct R r = { a, 1 }; *addr = r; } $ clang -O2 -o - -emit-llvm -S -c test.c ; ModuleID = 'test.c' target

> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On my out-of-tree target I have an intrinsic > > def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], > [llvm_i16_ty, llvm_i16_ty], > [IntrNoMem]>; > > that I want to translate to the

Hi, On 03/30/2016 11:38 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >> <mailto:mikael.holmen at ericsson.com>> wrote: >> >> i16 (divm16_pseudo …) >> >> stuff? >> >> I've tried >> (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16)

Hi, GVN seems to be running in an infinite loop on my example. I have attached the output of one iteration. I cant seem to reduce the testcase either. Any pointers to how to reduce the test case. THanks, Arushi GVN iteration: 8 GVN WIDENED LOAD: %0 = load i8* getelementptr inbounds (%struct.CHESS_POSITION* @search, i64 0, i32 23), align 2, !dbg !875 TO: %1 = load i16* bitcast (i8*

Hi, On my out-of-tree target I have an intrinsic def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], [llvm_i16_ty, llvm_i16_ty], [IntrNoMem]>; that I want to translate to the following instruction during instruction selection: def divm16_pseudo : MyPseudoInst< (outs aNh_0_7:$dst, aNh_0_7:$dst2), (ins