Sizeof a type?

Is there a way to get the sizeof a type? Say I've created a struct type without any explicit attribtues, and I want to call malloc() to allocate space for it. Can I get the size as an llvm::Constant* (or other llvm::Value*) given an llvm::StructType* or other llvm::Type*?

TIA,

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Rick Mann
Subject: [LLVMdev] Sizeof a type?

Is there a way to get the sizeof a type?

Look at the methods of the DataLayout class.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

Thanks! I seem to be able to do this

    llvm::DataLayout* dl = new llvm::DataLayout(module());
    uint64_t myStructSuze = dl->getTypeStoreSize(myStructType);

Is that the correct usage?

Hi all,

i'm writing a TXL (http://www.txl.ca) grammar and a revamp of bison/flex grammar for LLVM.

I've noticed an inconsistency regarding label naming conventions.

For instance, the following is a segment of legit LLVM assembly (human-readable) IR:

   br i1 %38, label %17, label %39
; <label>:39 ; preds = %._crit_edge
   ret void

However, ";" is a comment-line character. How is this interpreted, as a meta-comment? (a semantically important comment)?

Other branches appear using regular conventions:

   br i1 %exitcond, label %._crit_edge, label %.lr.ph
._crit_edge: ; preds = %.lr.ph, %.preheader

So, naturally I have some questions:

1) What is the differences among the branch labels? Differences in the formation (e.g. emitted by different passes?)

2) How to normalize the appearance of branch labels? I.e. is it possible to not emit the strange ; <label>:39 like ones?

3) Why <label>:39 and not 39: ?

4) Why not prefixing all labels with <label>?

Best regards
Nikolaos Kavvadias

Hi Rick,

Hi Nikolaos,

Hi all,

i'm writing a TXL (http://www.txl.ca) grammar and a revamp of bison/flex grammar
for LLVM.

I've noticed an inconsistency regarding label naming conventions.

For instance, the following is a segment of legit LLVM assembly (human-readable)
IR:

   br i1 %38, label %17, label %39
; <label>:39 ; preds = %._crit_edge
   ret void

However, ";" is a comment-line character. How is this interpreted, as a
meta-comment? (a semantically important comment)?

it's just a comment and has no semantic comment. You can delete it, it won't
make any difference.

Ciao, Duncan.

Thanks, Duncan. What's the difference between DataLayout::getTypeAllocSize and DataLayout::getTypeStoreSize?

Hi Duncan

  br i1 %38, label %17, label %39
; <label>:39 ; preds = %._crit_edge
  ret void

However, ";" is a comment-line character. How is this interpreted, as a
meta-comment? (a semantically important comment)?

it's just a comment and has no semantic comment. You can delete it, it won't
make any difference.

OK. However, in this case, how is the branch resolved? I mean that there is no obvious %39 label declared in the LLVM translation unit.

Best regards
Nikolaos Kavvadias

Hi Rick,

if you have DataLayout available, use the getTypeAllocSize method. If you don't
have information about the target then you can use ConstantExpr::getSizeOf. The
advantage of DataLayout is that it returns a number (eg: 8) while getSizeOf
returns a mysterious expression (the optimizers will simplify it to a number,
the same as getTypeAllocSize returns, if you provide them with DataLayout).

Thanks, Duncan. What's the difference between DataLayout::getTypeAllocSize and DataLayout::getTypeStoreSize?

the store size doesn't include alignment padding. Consider an x86 long double
type; it contains 10 bytes of info. It is aligned to a multiple of 4 bytes
on some platforms, and to a multiple of 8 bytes on others. On the first type
of platform getTypeAllocSize and C's sizeof will return 12, while on the second
type of platform they will both return 16. On all platforms the store size is
10 because that's the number of bytes that writing one of these guys to memory
will actually overwrite, the rest is padding.

Ciao, Duncan.

Hi Duncan

br i1 %38, label %17, label %39
; <label>:39 ; preds = %._crit_edge
ret void

However, ";" is a comment-line character. How is this interpreted, as a
meta-comment? (a semantically important comment)?

it's just a comment and has no semantic comment. You can delete it, it won't make any difference.

OK. However, in this case, how is the branch resolved? I mean that there is no obvious %39 label declared in the LLVM translation unit.

I can see that there is a certain convention; e.g. %39 is the assumed (implicit) label, if the %38 is the last defined temporary at that point of the function body.

So, I guess that if the following basic block has no explicit label, it acquires one by generating a new temporary. This is my deduction; I'm not sure it is correct though.

Best regards
Nikolaos Kavvadias

Hi Nikolaos,

Hi Duncan

  br i1 %38, label %17, label %39
; <label>:39 ; preds = %._crit_edge
  ret void

However, ";" is a comment-line character. How is this interpreted, as a
meta-comment? (a semantically important comment)?

it's just a comment and has no semantic comment. You can delete it, it won't
make any difference.

OK. However, in this case, how is the branch resolved? I mean that there is no
obvious %39 label declared in the LLVM translation unit.

labels don't determine where a basic block starts or stops, terminator
instructions do. It is possible to give a basic block a name, in which
case when writing out a .ll file that name will be output as a "label",
but the "label" has no functional utility, it's not a label like in real
assembler. If a basic block has no name then it is referred to in the .ll
by the number of the basic block, eg %39.

Ciao, Duncan.

Hi Nikolaos,

Hi Duncan

br i1 %38, label %17, label %39
; <label>:39 ; preds = %._crit_edge
ret void

However, ";" is a comment-line character. How is this interpreted, as a
meta-comment? (a semantically important comment)?

it's just a comment and has no semantic comment. You can delete it, it won't
make any difference.

OK. However, in this case, how is the branch resolved? I mean that there is no
obvious %39 label declared in the LLVM translation unit.

I can see that there is a certain convention; e.g. %39 is the assumed (implicit)
label, if the %38 is the last defined temporary at that point of the function body.

So, I guess that if the following basic block has no explicit label, it acquires
one by generating a new temporary. This is my deduction; I'm not sure it is
correct though.

that's it. It's the same for nameless instructions for example. Note that
these numbers only exist in the human readable IR. There has to be some way
when parsing human readable IR to know which basic block is being referred to.
That's what the numbers are for.

Ciao, Duncan.