search for: bitcast

...nstantExpression(cop, &TD); if (val != NULL) { errs() << "**" << *cop << " to \n--" << *val << "\n"; } } And this is the output i get, all constants should result in "i32 0" (at least this is what I need): **i32 bitcast (<4 x i8> zeroinitializer to i32) to --i32 bitcast (<4 x i8> zeroinitializer to i32) **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) **i32 bitcast (<...

...(val != NULL) > { > errs() << "**" << *cop << " to \n--" << *val << "\n"; > } > } > > And this is the output i get, all constants should result in "i32 0" (at least this is what I need): > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) > > **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to > --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) &...

...vailable URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090924/2b151f08/attachment.bin> -------------- next part -------------- File Name: sql_insert.cc [14447] File Name: [14 x i8] c"sql_insert.cc\00, LineNo: 1313, Inst: call void @llvm.dbg.stoppoint(i32 1313, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit134216 to { }*)) [14448] File Name: [14 x i8] c"sql_insert.cc\00, LineNo: 1316, Inst: call void @llvm.dbg.stoppoint(i32 1316, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit134216 to { }*)) [14449] File Name: [14 x i...

...(val != NULL) > { > errs() << "**" << *cop << " to \n--" << *val << "\n"; > } > } > > And this is the output i get, all constants should result in "i32 0" (at least this is what I need): > > **i32 bitcast (<4 x i8> zeroinitializer to i32) to > --i32 bitcast (<4 x i8> zeroinitializer to i32) > > **i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) to > --i32 sext (i8 trunc (i32 bitcast (<4 x i8> zeroinitializer to i32) to i8) to i32) &...

...code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void @llvm.memset.p0i8.i64(i8* %8, i8 0, i64 %7, i32 0, i1 false) %9 = bitcast %1* %0 to [8 x i8]* %10 = bitcast %0* %3 to [8 x i8]* %11 = load [8 x i8]* %9 store [8 x i8] %11, [8 x i8]* %10 %12 = call i8* @llvm.stacksave() %13 = alloca %0 %14 = getelementptr %0*...

...onditionConstant"* @_ZN6dexter18BinaryConditionAdd8evaluateEv5(%"class.dexter::BinaryConditionAdd"*) { entry: %1 = getelementptr inbounds %"class.dexter::BinaryConditionAdd"* %0, i32 0, i32 0, i32 1 %2 = load %"class.dexter::BaseCondition"** %1, align 8 %3 = bitcast %"class.dexter::BaseCondition"* %2 to %"class.dexter::BinaryConditionAdd"* %4 = getelementptr inbounds %"class.dexter::BinaryConditionAdd"* %3, i32 0, i32 0, i32 0, i32 1, i32 0 %5 = bitcast %union.anon* %4 to i64* store i64 4, i64* %5, align 8 %6 = getelementp...

I always thought that bitcast was a no-op internal llvm thing to fit the IR type system. I currently use sitofp, but I see your point. On Fri, Apr 17, 2015 at 1:04 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Dave, > > You can still bitcast between i32 and float, for example. > > Cheers, &gt...

...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* getelementptr inbounds (%struct.CHESS_POSITION* @search, i64 0, i32 23) to i16*), align 2 GVN COERCED INST: %0 = load i8* getelementptr inbounds (%struct.CHESS_POSITION* @search, i64 0, i32 23), align 2, !dbg !875 %1 = load i16* bitcast (i8* getelementptr inbounds (%struct.CHESS_POSITION*...

=== PROBLEM === (See this bug https://llvm.org/bugs/show_bug.cgi?id=26445) IR contains code for loading a float from float * and storing it to a float * address. After canonicalization of load in InstCombine [1], new bitcasts are added to the IR (see bottom of the email for code samples). This prevents select speculation in SROA to work. Also after SROA we have bitcasts from int32 to float. (Whereas originally after instCombine, bitcasts are only done on pointer types). === PROPOSED SOLUTION=== [1] implies that we ne...

...i=0;i<N;i++) { b[i] =c[i]; c[i]=0.0; } } for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %arrayidx = getelementptr inbounds [1000 x double], [1000 x double]* @c, i64 0, i64 %indvars.iv %0 = bitcast double* %arrayidx to i64* %1 = load i64, i64* %0, align 8, !tbaa !1 %arrayidx2 = getelementptr inbounds [1000 x double], [1000 x double]* @b, i64 0, i64 %indvars.iv %2 = bitcast double* %arrayidx2 to i64* store i64 %1, i64* %2, align 8, !tbaa !1 store double 0.000000e+00, double* %arrayid...

Seems like a new change in LLVM has made it so that bitcast of bitcast i8* %1 to %Foo* meaningless? If I'm correct is there any need for the bitcast anymore? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150417/e5bfbc64/attachment.html>

...aliases.c -c -o try_calls_aliases.bc opt 2>&1 -anders-aa -aa-eval -print-no-aliases -print-may-aliases -print-must-aliases try_calls_aliases.bc | egrep -e 'Alias|Function' > c I get: ........... Function: ptr_function_caller: 8 pointers, 2 call sites NoAlias: i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*) NoAlias: i32 (...)* %pf, i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*) ??????????????????????????????????????????????????????????????????????????????? NoAlias:...

...hecked: br label %vector.body, !dbg !18 vector.body: ; preds = %vector.body, %overflow.checked %index = phi i64 [ 0, %overflow.checked ], [ %index.next.1, %vector.body ], !dbg !18 %0 = getelementptr inbounds double, double* %a, i64 %index, !dbg !19 %1 = bitcast double* %0 to <2 x double>*, !dbg !20 %wide.load = load <2 x double>, <2 x double>* %1, align 8, !dbg !20 %2 = getelementptr double, double* %0, i64 2, !dbg !20 %3 = bitcast double* %2 to <2 x double>*, !dbg !20 %wide.load8 = load <2 x double>, <2 x double&g...

...Wed, Mar 16, 2016 at 8:34 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > How do it interact with the "typeless pointers" work? > Right - the goal of the typeless pointer work is to fix all these bugs related to "didn't look through bitcasts" in optimizations. Sometimes that's going to mean more work (because the code is leaning on the absence of bitcasts & the presence of convenient (but not guaranteed) type information to inform optimization decisions) but if we remove typed pointers while keeping optimization quality i...

...hen you think it might be ready? > It's a bit of an onion peel, really - since it will eventually involve generalizing/fixing every optimization that's currently leaning on typed pointers to keep the performance while removing the crutch they're currently leaning on. (in cases where bitcasts are literally just getting in the way, those won't require cleaning up & should just become "free performance wins" once we remove them, though) At the moment we can roundtrip every LLVM IR test case through bitcode and textual IR (reading/writing both formats) while using only...

On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead? An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't recommend it. It's a very useful invariant for...

I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block any development which would be accepted in the typeless pointer work wasn't planned. In my view, t...

Hi, I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64 BUILD_SPE64 i32, i32' node, which can be seen at https://reviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is no...

I don't really mind, but the intermediate stage will not be very nice: that a lot of code / tests that needs to be written with bitcast, and all of that while they are deemed to disappear. The added value isn't clear to me considering the added work. I'm not sure it wouldn't add more work for all the cleanup required by the "typeless pointer", but I'm not sure what's involved here and if David thinks t...

...->foo() + b->goo() + a->hoo() + b->hoo() + (*a + *b); >   delete a; delete b; >   return y; > } > > > Clang with -O4 -S -emit-llvm emits the following for main(): > > > define i32 @main() { >   %1 = tail call noalias i8* @_Znwm(i64 16), !dbg !70 >   %2 = bitcast i8* %1 to %class.A*, !dbg !70 >   tail call void @llvm.dbg.value(metadata !{%class.A* %2}, i64 0, metadata > !68) >   tail call void @llvm.dbg.value(metadata !71, i64 0, metadata !69) >   tail call void @llvm.dbg.value(metadata !{%class.A* %2}, i64 0, metadata > !66) >   tail call...