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

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.

How many times will a typical client call getOperand on your helper when it
wraps a 10,000 element ConstantAggregateZero?

With CAZ the client is force to think about this case, and often handles it much
much more efficiently.  CAZ is a time optimization as well as a space
optimization.

-Chris

On Jan 21, 2012, at 12:03 AM, Stepan Dyatkovskiy <STPWORLD at narod.ru>
wrote:
> 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.

You right here. If you know how to handle it more efficiently, wrapper will bad
idea, since it will invoked 10,000 times. We must think always and select most
efficient and clean way.
Though, there is also cases when we really need to transform it to 10,000 zeroes
(just look at CBackend.cpp, when we print constant arrays, string #1027). There
is also cases when we need to get either operand[i] or zero (SCCP.cpp, str
#413). Both for CBackend and for SCCP we can reduce code size keeping
performance on the same level.

-Stepan.

21.01.2012, 17:50, "Chris Lattner" <clattner at
apple.com>:
> How many times will a typical client call getOperand on your helper when it
wraps a 10,000 element ConstantAggregateZero?
>
> With CAZ the client is force to think about this case, and often handles it
much much more efficiently.  CAZ is a time optimization as well as a space
optimization.
>
> -Chris
>
> On Jan 21, 2012, at 12:03 AM, Stepan Dyatkovskiy <STPWORLD at
narod.ru> wrote:
>
>>  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.

Sorry, forgot to reply-all

---------- Forwarded message ----------
From: Anton Korobeynikov <anton at korobeynikov.info>
Date: Sat, Jan 21, 2012 at 20:59
Subject: Re: [LLVMdev] How to force the creation of arrays with zeroes?
To: Stepan Dyatkovskiy <STPWORLD at narod.ru>

> Though, there is also cases when we really need to transform it to 10,000
zeroes (just look at CBackend.cpp, when we print constant arrays, string #1027).
There is also cases when we need to get either operand[i] or zero (SCCP.cpp, str
#413). Both for CBackend and for SCCP we can reduce code size keeping
performance on the same level.
In these 2 particular cases the changes of the code size can
definitely be neglected. Even more, in SCCP the use of CAZ is a
performance win, since we do not have to check at all operands are
zero, we already (!) know this.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Anton, in a solution without CAZ, isNullValue can just return true when it
sees the special "this ConstantArray is all zero" flag.  So all the
places that
now look for CAZ can just use isNullValue instead and there need be no
performance loss.  That said, CAZ is more "in your force" so less
likely to be
forgotten about.  Another interesting possibility is to handle more than just
all zero values: if a constant array has many repeated elements, maybe the
array could be stored in a compressed form.  An all zeros array would just be a
special case of this.

Ciao, Duncan.

On 21/01/12 18:13, Anton Korobeynikov wrote:
> Sorry, forgot to reply-all
>
> ---------- Forwarded message ----------
> From: Anton Korobeynikov<anton at korobeynikov.info>
> Date: Sat, Jan 21, 2012 at 20:59
> Subject: Re: [LLVMdev] How to force the creation of arrays with zeroes?
> To: Stepan Dyatkovskiy<STPWORLD at narod.ru>
>
>
>> Though, there is also cases when we really need to transform it to
10,000 zeroes (just look at CBackend.cpp, when we print constant arrays, string
#1027). There is also cases when we need to get either operand[i] or zero
(SCCP.cpp, str #413). Both for CBackend and for SCCP we can reduce code size
keeping performance on the same level.
> In these 2 particular cases the changes of the code size can
> definitely be neglected. Even more, in SCCP the use of CAZ is a
> performance win, since we do not have to check at all operands are
> zero, we already (!) know this.
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
>