search for: bitcaster

Displaying 20 results from an estimated 2193 matches for "bitcaster".

Did you mean: bitcasted
2011 Feb 15
3
[LLVMdev] How to use ConstantFoldConstantExpression?
Hello, i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, however I am not able to make it fold anything. Could you please give me some advice, what I am doing wrong? My code looks something like this: //data layout is obtained from clang-generated code for triple arm-none-linux-gnueabi with added v32:32:32 const char* const TARGET_DATA_LAYOUT =
2011 Feb 15
0
[LLVMdev] How to use ConstantFoldConstantExpression?
I forgot to mention, that I use LLVM release 2.8, I did not try it with the latest revision, but I expect that I am rather doing something wrong than using non-implemented functions. On Tue, 15 Feb 2011 14:09:57 +0100, ihusar <ihusar at fit.vutbr.cz> wrote: > Hello, > > i need to fold constants, i found that a function ConstantFoldConstantExpression could be used, > however
2009 Sep 24
3
[LLVMdev] Is line number in DbgStopPointInst in LLVM accurate?
Dear developers, When I try to map line numbers in source code back to LLVM basicblocks, I meet some problems: there is a source file with 1500 lines of code, but when I use BasicBlockPass to collect all DbgStopPoint instructions in this file, I can only get 500 lines of code. The source code and the collected results are both attached. Is there any way to map line numbers
2011 Feb 15
2
[LLVMdev] How to use ConstantFoldConstantExpression?
Adam, I just fixed this issue a few days ago. A version from the trunk should work for you. Cheers, Nadav -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ihusar Sent: Tuesday, February 15, 2011 15:52 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] How to use ConstantFoldConstantExpression? I forgot to mention, that I use
2011 Nov 02
1
[LLVMdev] [LLVMDev]: UNREACHABLE executed!
Hi, guys! I write a virtual machine which uses LLVM as back-end 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
2013 Nov 23
2
[LLVMdev] GVN fails with bitcasts
Hi, i have the following code: define internal %"struct.dexter::ConditionConstant"* @_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
2015 Apr 17
2
[LLVMdev] Is bitcast now needed in LLVM?
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, > > James > > On Fri, 17 Apr 2015 at 09:03 Dave Pitsbawn
2011 May 03
3
[LLVMdev] GVN Infinite loop
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*
2016 Mar 16
3
RFC: A change in InstCombine canonical form
=== 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.
2016 Aug 17
2
Loop vectorization with the loop containing bitcast
Hi , The following loop fails to be vectorized since the load c[i] is casted as i64 and the store c[i] is double. The loop access analysis gives up since they are in different types. Since these two memory operations are in the same size, I believe the loop access analysis should return forward dependence and thus the loop can be vectorized. Any comments? Thanks, Jin #define N 1000 double
2015 Apr 17
3
[LLVMdev] Is bitcast now needed in LLVM?
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>
2009 Oct 02
1
[LLVMdev] alias analysis and functions
Hi, I am trying to use alias analysis (Anderson) and noticed that for pointers to functions I don't get the expected result: a pointer that clearly may point to a function is reported as NoAlias. I use -anders-aa -aa-eval -print-no-aliases -print-may-aliases -print-must-aliases Here is a test case: ///////////////try_calls_aliases.c #include <stdio.h> typedef int (*PF)(); PF
2015 Sep 20
2
simplifycfg not happening?
The following function compiles with -O3 into the following IR. http://llvm.org/docs/Passes.html#simplifycfg-simplify-the-cfg says - Eliminates a basic block that only contains an unconditional branch. but the first and third blocks in the compiled function only contain an unconditional branch; I would have expected them to be eliminated. What am I missing? double f(double *a) { for (int i
2016 Mar 16
2
RFC: A change in InstCombine canonical form
On 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
2016 Mar 16
3
RFC: A change in InstCombine canonical form
On Wed, Mar 16, 2016 at 11:00 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > David, > > Could you give us an update on the status of typeless pointer work? How > much work is left and when 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
2015 Dec 01
3
Endianness for multi-word types
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
2016 Mar 22
2
RFC: A change in InstCombine canonical form
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, this is one of the largest
2019 Jan 02
5
Potential bug in SelectionDAGLegalize::ConvertNodeToLibcall()?
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 not legal on line 24. There should be no
2016 Mar 22
4
RFC: A change in InstCombine canonical form
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
2011 Dec 09
0
[LLVMdev] Implementing devirtualization
On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote: > We've got the following test case: > > > class A { > public: >   int x; >   A(int x) : x(x) {} >   int hoo() {return 4;} >   virtual int foo() {return x;} >   virtual int goo() {return foo()+10;} >   virtual int operator+(A &a) { >     return x + a.x; >   } > };