similar to: [LLVMdev] How to get the exact integer from a Value

Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] How to get the exact integer from a Value"

2013 Sep 06
1
[LLVMdev] How to get the exact integer from a Value
Thank you, Chuck! It works. And, please forgive my greed : ), another question: I found that: In IR of llvm which generated by my testing code, there is a Inst said " getelementptr inbounds [5 x i32]* %idxarr, i32 0, i64 3". The idxarr is my array name, and I think Inst means getting the ptr of the 4th (3+1) element of array "idxarr", am I right? So the question is: how can
2013 Sep 06
0
[LLVMdev] How to get the exact integer from a Value
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of weixuegong > Subject: [LLVMdev] How to get the exact integer from a Value > I have a Value* type named indexValue, and the type is i32. > I think "indexValue" must hold a number which type is int. Correct, but it might not be a constant. > ConstantInt* CI =
2008 Jul 07
2
[LLVMdev] (GEP) Index validity
Hi all, I'm fiddling around a bit with programmatically created GEP instructions, which is failing when using i64 for any indix, except the first. The reason behind this, is that StructureType::indexValid only accepts Value* that are constant ints of width 32. I can't really see why this limitation is here. SequentialType solves this slightly differently, it allows for both 32 and 64
2008 Jul 07
0
[LLVMdev] (GEP) Index validity
Hi all, I just found that TargetData also contains a similar assert, and that I forgot a "return" in my previous patch. Here's an updated patch, which allows to use any integer to index a CompositeType. It seems this enables GEP to work with any integer value as well, I tested indexing a struct with a i16 an i64 (also through llc). This should still be adressed somewhere, unless we
2008 Jul 10
2
[LLVMdev] (GEP) Index validity
Hi all, any comments about this patch? I'd like to get it out of my working copy :-) Gr. Matthijs > Index: lib/VMCore/Type.cpp > =================================================================== > --- lib/VMCore/Type.cpp (revision 53136) > +++ lib/VMCore/Type.cpp (working copy) > @@ -394,9 +394,8 @@ > > bool StructType::indexValid(const Value *V) const { >
2010 Apr 22
3
[LLVMdev] Operand, instruction
Hello, how to get the numerical value of an constant operand? For ex. %tmp = mul i32 %indvar, 6 , in this instruction second operand is a numerical constant with value 6. But i am only able to print it by using getOperand(1), not able to store it in any integer variable. Using getName() returns a empty string. Is there any way to solve this problem? Thank you. John Criswell-2 wrote: > >
2010 Apr 22
0
[LLVMdev] Operand, instruction
if (ConstantInt *c = (ConstantInt *) dyn_cast<ConstantInt>(index)){ errs() << "And it's a constant!!!!!!1111oneone!! (" <<c->getZExtValue() << ")\n"; } -- "Believe you can, believe you can't; either way you're right."  -Henry Ford -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
2017 Jun 11
2
Force casting a Value*
On 11 June 2017 at 11:32, Nikodemus Siivola <nikodemus at random-state.net> wrote: > On Sun, Jun 11, 2017 at 7:49 PM, Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On 11 June 2017 at 07:53, David Blaikie <dblaikie at gmail.com> wrote: >> >>> Sounds like you're looking for reinterpret_cast: http://en.cp
2017 Jun 11
2
Force casting a Value*
On 11 June 2017 at 12:05, Tim Northover <t.p.northover at gmail.com> wrote: > On 11 June 2017 at 11:56, Dipanjan Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I can't pass var_value to a function accepting uint64_t. LLVM complains > > about broken function call. > > Well, yes. var_value has type "ConstantInt *", not uint64_t. Assuming
2012 Nov 16
5
[LLVMdev] Assert with getZExtValue()?
Was hoping it might get some help or a better explanation of this: /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. Program received signal SIGABRT, Aborted. 0x00007ffff6eb4d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64
2010 Jun 23
1
[LLVMdev] LLVM help
Sir I am trying to get the constant 2 in instruction y=x+2; Its intermediate representaton is like %y=add nsw i32 %x , 2 If I use getOperand(2).getName() then I get null string. How can I get the value 2 ? Regards Rahul Goyal -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100623/21222621/attachment.html>
2010 Jul 16
2
[LLVMdev] Strange behavior when converting arrays to strings
Hello, I found saw some strange behavior (to me) when converting constant arrays to strings. Consider the following example: std::string Text = "HelloWorld"; unsigned TextLengthBefore = Text.length(); ConstantArray *pArray = dyn_cast<ConstantArray>(llvm::ConstantArray::get(pModule->getContext(), Text, true)); unsigned NumElements = pArray->getNumOperands(); Text =
2017 Jun 12
2
Force casting a Value*
On 11 June 2017 at 14:04, don hinton <hintonda at gmail.com> wrote: > Assuming you know it's a 64 bit value, and the function you are calling > takes a uint64_t, try this: > The values from the test program are of type: i32/i32*/i32**. Can't I interpret these as uint64_t some way? > > Value* args[] = {store_inst->getOperand(0)}; > > > On Sun, Jun 11,
2016 Feb 07
3
[PATCH] strlen -> strnlen optimization
This addition converts strlen() calls to strnlen() when the result is compared to a constant. For example, the following: strlen(s) < 5 Becomes: strnlen(s, 5) < 5 That way, we don't have to walk through the entire string. There is the added overhead of maintaining a counter when using strnlen(), but I thought I'd start with the general case. It may make sense to only use this
2010 Mar 15
3
[LLVMdev] [patch] Writing ConstantUnions
Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------
2008 Sep 22
0
[LLVMdev] Overzealous PromoteCastOfAllocation
On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the
2010 Jul 28
0
[LLVMdev] Strange behavior when converting arrays to strings
Hi, I haven't seen a response and I'm curious if I should submit a patch for this. Thanks, Javier From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Martinez, Javier E Sent: Friday, July 16, 2010 3:20 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Strange behavior when converting arrays to strings Hello, I found saw some strange behavior (to
2011 Jul 01
0
[LLVMdev] Reporting errors in inline assembly
On Fri, Jul 1, 2011 at 4:09 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I want to report a problem with an inline assembly instruction from a code generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal
2008 Sep 13
3
[LLVMdev] Overzealous PromoteCastOfAllocation
Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so > it would be nice to update the alignment field of
2009 Nov 10
1
[LLVMdev] Altivec vs the type legalizer
Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful