Displaying 6 results from an estimated 6 matches for "getsizeinbytes".
2009 Jun 18
1
[LLVMdev] Explicitly Freeing Allocas
...blem is, the TargetData object from
ExecutionEngine gives me a size of 12 for a struct containing a pointer and
an i64 (on a 32-bit machine). However, the generated code seems to assume an
alignment of 8, and tries to read the i64 value at offset 8, which obviously
reads an invalid value.
Does the getSizeInBytes() method from StructLayout not take the alignment
into account?
- Max
Olivier Meurant wrote:
>
> In the TargetData class (available from you ExecutionEngine), you have
> some
> informations available (such as StructLayout...).
>
>
> On Thu, Jun 18, 2009 at 5:08 PM, Nyx &l...
2010 Oct 13
1
[LLVMdev] address-units
...d generalize anything that works
in terms of bytes to work in terms of address units. I think you'll
need
to extend the datalayout string syntax to support an address unit
size (in bits), and to add an address unit size field to the TargetData
class. You'll also need to change APIs like getSizeInBytes to
getSizeInAddressUnits.
Then, you can change your target datalayout string to be in terms of
16-bit address units instead of 8-bit address units.
Then there are other places in LLVM which hardcode "8" constants
and "i8*" types; these can be fixed once the TargetData changes...
2009 Apr 01
2
[LLVMdev] adjust address calculus for an architecture that does not address bytes
> > At first I thought this could be handled when lowering
> loads and stores, but I realize that I can only catch the
> targeted addresses of loads/stores here - however address
> calculation nodes may occur anywhere in a DAG.
> >
> > So my first impulse would be to adjust the constants when
> the GEP instructions are transformed to ADDs. Afaics his
> would mean
2009 Jun 18
0
[LLVMdev] Explicitly Freeing Allocas
In the TargetData class (available from you ExecutionEngine), you have some
informations available (such as StructLayout...).
On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote:
>
> That sounds rather cumbersome, is there no simpler way to get the actual
> size
> of a struct?
>
>
> John Criswell wrote:
> >
> > Nyx wrote:
> >>
2009 Jun 18
2
[LLVMdev] Explicitly Freeing Allocas
That sounds rather cumbersome, is there no simpler way to get the actual size
of a struct?
John Criswell wrote:
>
> Nyx wrote:
>> Hello,
>>
>> I would just like to ask if it's possible to explicitly free allocas.
>> This
>> is because I need to call functions that take structs of different sizes
>> as
>> input, (possibly inside of loops) and I
2019 May 09
3
RFC: On removing magic numbers assuming 8-bit bytes
I agree that consensus seems to be missing. There's definitely some
assumptions, and more in particular, API and usage assumptions around
8 bit bytes in the backends. Also: How do you plan on keeping these
assumptions from creeping back in?
-eric
On Thu, May 9, 2019 at 10:30 AM JF Bastien via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> On May 9, 2019, at 5:29 AM,