llvm dev - Jan 2012 - [LLVMdev] How to force the creation of arrays with zeroes?

Hi all. I propose to use wrapper for this kind of constant objects. 

Consider next code:

Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx));
Constant* ArrayItem;
if (!isa<ConstantAggregateZero>(C))
  ArrayItem = reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx));
else
  ArrayItem = ZeroInt;

Code analog within wrapper:

 ConstOrZero C(I->getOperand(idx));
 Constant* ArrayItem = C.getOperand(ArrItemIdx); // Unpleasant work with
isa<> inside.

Advantages of this approach is that ConstantAggregateZero saves memory and we
use it everywhere.
And in the same time we needn't dance with isa<ConstantAggregateZero>.

If you find it fine, please look at the patch in attachment.

-Stepan

20.01.2012, 14:50, "Duncan Sands" <baldrick at
free.fr>:
> Hi Anton,
>
>>>  you can't, you can only get a ConstantAggregateZero.  This is
actually kind of
>>>  annoying, and means that places expecting a ConstantArray have to
remember to
>>>  also check for ConstantAggregateZero.  Perhaps there's a good
reason for the
>>>  current design, but if not it would be great to eliminate this
wart.
>>  Well, I think the main reason it so reduce the size of .ll / .bc when
>>  all operands are zero.
>>  If the array / struct is really big then this can save a lot of space.
>
> isn't this an orthogonal issue?  A ConstantVector consisting of only
zeros
> doesn't have to be represented by storing a vast array of zero values,
it
> could be special cased internally by setting some kind of flag.  If done
right,
> an all zero ConstantVector would then act exactly the same as every other
kind
> of ConstantVector as far as users of ConstantVector can tell, but
wouldn't take
> up a lot of storage.  Instead, what we have now is essentially the same
system
> only with the flag exposed to users (ConstantAggregateZero playing the role
of
> the flag) so that all users have to worry about it, rather than this flag
being
> hidden in the implementation of ConstantVector and ConstantStruct.
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: const-or-zero.patch
Type: application/octet-stream
Size: 5951 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120121/ab57d7e1/attachment.obj>

I'd really rather not do this.  Faking that large zero filled array is
represented with ConstantArray means that the compiler will inevitably end up
calling getOperand on each of those elements, burning a ton of compile time.

-Chris

On Jan 20, 2012, at 12:16 PM, Stepan Dyatkovskiy <STPWORLD at narod.ru>
wrote:
> Hi all. I propose to use wrapper for this kind of constant objects. 
> 
> Consider next code:
> 
> Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx));
> Constant* ArrayItem;
> if (!isa<ConstantAggregateZero>(C))
>  ArrayItem =
reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx));
> else
>  ArrayItem = ZeroInt;
> 
> Code analog within wrapper:
> 
> ConstOrZero C(I->getOperand(idx));
> Constant* ArrayItem = C.getOperand(ArrItemIdx); // Unpleasant work with
isa<> inside.
> 
> Advantages of this approach is that ConstantAggregateZero saves memory and
we use it everywhere.
> And in the same time we needn't dance with
isa<ConstantAggregateZero>.
> 
> If you find it fine, please look at the patch in attachment.
> 
> -Stepan
> 
> 20.01.2012, 14:50, "Duncan Sands" <baldrick at free.fr>:
>> Hi Anton,
>> 
>>>>  you can't, you can only get a ConstantAggregateZero.  This
is actually kind of
>>>>  annoying, and means that places expecting a ConstantArray have
to remember to
>>>>  also check for ConstantAggregateZero.  Perhaps there's a
good reason for the
>>>>  current design, but if not it would be great to eliminate this
wart.
>>>  Well, I think the main reason it so reduce the size of .ll / .bc
when
>>>  all operands are zero.
>>>  If the array / struct is really big then this can save a lot of
space.
>> 
>> isn't this an orthogonal issue?  A ConstantVector consisting of
only zeros
>> doesn't have to be represented by storing a vast array of zero
values, it
>> could be special cased internally by setting some kind of flag.  If
done right,
>> an all zero ConstantVector would then act exactly the same as every
other kind
>> of ConstantVector as far as users of ConstantVector can tell, but
wouldn't take
>> up a lot of storage.  Instead, what we have now is essentially the same
system
>> only with the flag exposed to users (ConstantAggregateZero playing the
role of
>> the flag) so that all users have to worry about it, rather than this
flag being
>> hidden in the implementation of ConstantVector and ConstantStruct.
>> 
>> Ciao, Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> <const-or-zero.patch>

Hi Chris. There is no zero arrays created. Probably this patch is not optimal
and I'll reworked it today. But the main idea is keep a single zero-item
when ConstantAggregateZero was wrapped and return this zero item as result of
getOperand call.
Note that wrapper has no parent classes, it has very local and short lifetime
(method body), it exists outside the LLVMContext and needed for replacement of
isa<ConstantAggregateZero>(C) checks only.

-Stepan

21.01.2012, 08:12, "Chris Lattner" <clattner at
apple.com>:
> I'd really rather not do this.  Faking that large zero filled array is
represented with ConstantArray means that the compiler will inevitably end up
calling getOperand on each of those elements, burning a ton of compile time.