llvm dev - Jul 2017 - type information about instruction

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>

On 21 July 2017 at 07:52, Anastasiya Ruzhanskaya
<anastasiya.ruzhanskaya at frtk.ru> wrote:
> 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?
The Type of the "or" instruction should be fine without messing around
with operands, whether it's dead or not.

First, make sure you're looking at the Instruction you think you are
(sounds obvious, but I'm frequently not) by calling dump:
"I->dump()"
either in the actual C++ or in a debugger. You can also dump the Type
itself to make sure it's i32. The more sanity checks the better!

Other than that, what function are you using to get the size?

Cheers.

Tim.

You are totally right:) Silly faults with confusing the instructions. Thank
you again!

2017-07-21 17:03 GMT+02:00 Tim Northover <t.p.northover at gmail.com>:
> On 21 July 2017 at 07:52, Anastasiya Ruzhanskaya
> <anastasiya.ruzhanskaya at frtk.ru> wrote:
> > 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?
>
> The Type of the "or" instruction should be fine without messing
around
> with operands, whether it's dead or not.
>
> First, make sure you're looking at the Instruction you think you are
> (sounds obvious, but I'm frequently not) by calling dump:
"I->dump()"
> either in the actual C++ or in a debugger. You can also dump the Type
> itself to make sure it's i32. The more sanity checks the better!
>
> Other than that, what function are you using to get the size?
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/2cb603cb/attachment.html>