Displaying 8 results from an estimated 8 matches similar to: "[LLVMdev] please review this fix for PR3510"
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 Mar 15
0
[LLVMdev] [patch] Writing ConstantUnions
On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote:
> Hello,
>
> I noticed a bit of a gap in the current code for unions: a
> ConstantUnion cannot be written out to .ll.
I've been continuing plugging gaps as I find them, which might not be
the best way to solve this problem, but it has produced something that
seems to do roughly what I expect.
I've split it into
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 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
2011 Feb 04
3
[LLVMdev] ConstantBuilder proposal
Here's a sketch of what I am proposing for ConstantBuilder.
I'd like feedback on naming conventions, doc comments, etc.
//===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++
-*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
2008 Jul 10
0
[LLVMdev] (GEP) Index validity
I don't think this is right. According to llvm documentation:
The index types specified for the 'getelementptr' instruction depend
on the pointer type that is being indexed into. Pointer and array
types can use a 32-bit or 64-bit integer type but the value will
always be sign extended to 64-bits. Structure and packed structure
types require i32 constants.
Evan
On Jul 10,
2008 Jul 22
2
[LLVMdev] BITS_BIG_ENDIAN in llvm-gcc
There are various functions in llvm-convert.cpp that depend on BITS_BIG_ENDIAN:
TreeToLLVM::EmitLoadOfLValue()
TreeToLLVM::EmitMODIFY_EXPR()
InsertBitFieldValue()
ProcessBitFieldInitialization()
The comments say things like:
// If this target has bitfields laid out in big-endian order, invert the bit
// in the word if needed.
// If this is a big-endian bit-field, take the top