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]