[llvm-dev] type information about instruction

[Anastasiya Ruzhanskaya via llvm-dev]

Thank you for the answer. So, as I understood, to get the type of the "or"
instruction (which I cannot access further as Value , because it is
actually a dead instruction), I should get the type of one of its'
operands, yes? because the example with ret is quite understandable, but it
seems really strange that such instructions as add, and , which define the
actual values can have their Types be accessed only from the operands.

2017-07-21 16:35 GMT+02:00 Tim Northover <t.p.northover at gmail.com>:

> On 21 July 2017 at 04:49, Anastasiya Ruzhanskaya via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I would like to keep info about size and type info of all instructions (
> and
> > Values at the same time). I can do this by extracting type of the Values,
> > but if I have still some unused instructions , I can't keep track on
> them. I
> > try to convert them to Value and get the type or simply get the type of
> > instruction, but have the following error:
> >
> > Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is
> > unsized!"' failed.
>
> You've got two issues you need to take account of here.
>
> First is that the Type of an instruction is the type of the Value it
> produces, which isn't necessarily what you want. Some instructions
> ("ret" in your case, but also other branches, and "store") produce no
> actual value that can be used later so their type is "void" which has
> no size. What you probably want is the type of one of the operands
> (RetI->getOperand(0)->getType() for example would be "i32" in your
> example).
>
> The other thing you're likely to hit is that aggregate types can have
> sizes that depend on the DataLayout. For example {i32, i64} might have
> size 96 or 128 depending on the ABI. So you should be using
> DataLayout::getTypeSizeInBits if you need to cover these cases instead
> of Type's own accessor.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/14bd47e5/attachment.html>