search for: iscastable

Displaying 15 results from an estimated 15 matches for "iscastable".

Did you mean: castable
2014 Sep 01
2
[LLVMdev] Instrumenting Various Types Using Single Instrumentation Function
...to create different instrumentation functions for different data types. Can I cast say i32 value to NumericType value in my instrumentation code, without inserting additional instructions in my benchmark code. I tried inserting bitcast instructions and it doesn't work for me... if(!CastInst::isCastable(Lvals[j]->getType(), UnionVar->getType())){ errs()<<"CAST TO NumericType NOT POSSIBLE\n"; exit(0); } CastInst *I = CastInst::CreateZExtOrBitCast(Lvals[j], UnionVar->getType(), "", F); Is this even possible or some other method will be better?...
2011 Nov 17
2
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html
2011 Nov 21
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias, I've attached an updated patch. It contains a few bug fixes and many (refactoring and coding-convention) changes inspired by your comments. I'm currently trying to fix the bug responsible for causing a compile failure when compiling test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the pass begins to fuse instructions in a basic block in this file, the aliasing
2016 Jul 22
2
HEAD compilation causes gcc internal error
After worked around the problem in SimplifyCFG.cpp (calling isCast() instead of comparing opcode), I hit another gcc crash for FunctionImport.cpp line 480, which I have no idea what's wrong with the code. "Luckily", I found gcc4.8.2 and gave it a try, both crashes are gone. *New problem though:* /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp: In member function
2011 Nov 16
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in
2011 Nov 15
3
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because
2010 Jul 15
1
[LLVMdev] Figuring out the parameters of the Call Instruction
Hi Duncan, Thanks for pointing out my mistake. I will reword my questions. //C code int var1; //global int a, b; foo(a, b); bar(c); generates following //LLVM IR %1 = load a; %2 = load b; call foo(%1, %2) call bar(@var1) CallInst.getOperand(1).getNameStr() on foo, returns null, but on bar returns var1. Similarly, for call void @p_ptr(i64 ptrtoint (%struct.my_struct* @abc to i64)) nounwind,
2019 Dec 19
2
Moving to ORCv2 - Where are my global constructors and destructors?
Heyho, Recently I tried out the ORCv2 JIT, especially the LLJIT. I gotta say, that I really like the new interface and the way you use it! However there is one thing I'm missing. I wrote a small bit code file, which should force having a global constructor. int wuff(); __declspec(noinline) int miau() { printf("Huhuhu"); return wuff(); } const int x = miau(); When I
2011 Dec 02
5
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired
2011 Dec 14
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias, I've attached an updated copy of the patch. I believe that I accounted for all of your suggestions except for: 1. You said that I could make AA a member of the class and initialize it for each basic block. I suppose that I'd need to make it a pointer, but more generally, what is the thread-safely model that I should have in mind for the analysis passes (will multiple threads
2011 Nov 23
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile
2011 Dec 02
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: > On 11/23/2011 05:52 PM, Hal Finkel wrote: > > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > >>> > > Tobias, > >>> > > > >>> > > I've attached an updated patch. It contains a few bug fixes
2011 Nov 22
5
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >
2016 Jul 22
2
HEAD compilation causes gcc internal error
Sure this is more likely a gcc bug. However, same toolchain compiled without any problems a week ago. Also, in some organizations, upgrading gcc is very hard if not impossible. On Fri, Jul 22, 2016 at 11:11 AM, Paulo Matos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 22/07/16 20:08, Welson Sun via llvm-dev wrote: > > This is gcc4.8.0 compiling HEAD synced on
2012 Jan 27
3
[LLVMdev] How to get the string value?
Thanks Duncan, Yes, it is a ConstantExpr! Thank you! Now trying to find a clue in ConstantExpr's functions to get that string :-) Regards, Welson On Thu, Jan 26, 2012 at 9:04 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Welson Sun, > > > Hi, if I have some LLVM code like this: > > > > @.str = private unnamed_addr constant [7 x i8]