llvm dev - Jul 2017 - type information about instruction

Hello,
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.

This is second or instruction:
  %1 = or i32 10, 20
  %2 = or i32 %1, 10
  ret i32 %1

What can be done in this case?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/6ec913d1/attachment.html>

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.

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>