search for: tmpcast

...ed over %ref.tmp? If they allocate the same number of bytes, why is %ref.tmp not given preference as it comes first in the order? *Malformed IR at the end of Stack Coloring pass:*entry: %a = alloca %struct.e, align 1 %ref.tmp = alloca { <2 x float>, <2 x float> }, align 8 %tmpcast = bitcast { <2 x float>, <2 x float> }* %0 to %class.d* ... %tmp = alloca %"struct.e::f", align 8 %0 = bitcast %"struct.e::f"* %tmp to { <2 x float>, <2 x float> }* ... ret void *Steps to reproduce:* For debugging purposes, I have mo...

...6-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-apple-darwin11.2.0" define void @f_fu(float* nocapture %RET, float* nocapture %aFOO, float %b) nounwind { for_exit: %x = alloca i64, align 16 %tmpcast = bitcast i64* %x to [8 x i8]* store i64 -1, i64* %x, align 16 %ptr_cast_for_load = bitcast float* %aFOO to <4 x i32>* %masked_load202 = load <4 x i32>* %ptr_cast_for_load, align 4 %gather_bitcast = bitcast <4 x i32> %masked_load202 to <4 x float> %float2uint = fpt...

...ack locations to pass arguments depending on the alignment of the type of the argument that is passed. Breakpoint 2 at llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:1667 1667 return EverMadeChange; (gdb) p F.dump() define i32 @main() nounwind { entry: %dw = alloca i64, align 8 %tmpcast = bitcast i64* %dw to %struct.DWordS_struct* %ls = alloca %struct.LargeS_struct, align 8 store i64 416611827730, i64* %dw, align 8 %i = getelementptr inbounds %struct.LargeS_struct* %ls, i32 0, i32 0 store i32 21, i32* %i, align 8, !tbaa !0 %d = getelementptr inbounds %struct.LargeS_struc...

...using vector extracts: struct a { float w, x, y, z; }; float foo(struct a b) { return b.w+b.x+b.y+b.z; } %struct.a = type { float, float, float, float } define float @foo(double %b.0, double %b.1) nounwind { entry: %b_addr = alloca { double, double } ; <{ double, double }*> [#uses=4] %tmpcast = bitcast { double, double }* %b_addr to %struct.a* ; < %struct.a*> [#uses=3] %tmp1 = getelementptr { double, double }* %b_addr, i32 0, i32 0 ; <double*> [#uses=1] store double %b.0, double* %tmp1, align 8 %tmp3 = getelementptr { double, double }* %b_addr, i32 0, i32 1 ; <...

...somewhere. This i32* appears used, but can later be removed (you'll see why). Now, when I run instcombine over this code, I get the following (other functions left out, they are unchanged). define void @foo(i16 %A, i16 %B) { entry: %V = alloca i32 ; <i32*> [#uses=3] %tmpcast = bitcast i32* %V to { i16, i16 }* ; <{ i16, i16 }*> [#uses=1] %V1 = bitcast i32* %V to i16* ; <i16*> [#uses=2] %V2 = getelementptr { i16, i16 }* %tmpcast, i32 0, i32 1 ; <i16*> [#uses=2] store i16 %A, i16* %V1, align 4 stor...

Using MM registers is wrong unless the user has specifically asked for it, which doesn't seem to be the case here. In the awesome MMX architecture, touching an MM register makes subsequent x87 operations fail unless an EMMS instruction is issued first; none of the compilers here are smart enough to insert EMMS instructions in the right places, so the only safe thing is not to use

...llvm-dis -o - [...] define %3 @_ZN7WebCore15GraphicsContext19roundToDevicePixelsERKNS_9FloatRectE(%"class.WebCore::GraphicsContext"* %this, %"struct.WebCore::FloatRect"* %rect) nounwind ssp align 2 { %roundedOrigin = alloca i64, align 8 ; <i64*> [#uses=3] %tmpcast = bitcast i64* %roundedOrigin to %"class.WebCore::FloatSize"* ; <%"class.WebCore::FloatSize"*> [#uses=2] %roundedLowerRight = alloca %"class.WebCore::FloatSize", align 4 ; <%"class.WebCore::FloatSize"*> [#uses=3] %1 = bitcast i64* %roundedOrig...

...can later be > removed (you'll see why). > > Now, when I run instcombine over this code, I get the following (other > functions left out, they are unchanged). > define void @foo(i16 %A, i16 %B) { > entry: > %V = alloca i32 ; <i32*> [#uses=3] > %tmpcast = bitcast i32* %V to { i16, i16 }* ; > <{ i16, i16 }*> [#uses=1] > %V1 = bitcast i32* %V to i16* ; <i16*> [#uses=2] > %V2 = getelementptr { i16, i16 }* %tmpcast, i32 0, i32 > 1 ; <i16*> [#uses=2] > store i16 %A...

Hi, I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it boggles the mind. Below I provide the optimized asm that is produced from

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