llvm dev - Jan 2014 - [LLVMdev] A question about everyone's favorite constructs: NSW and NUW

On Tue, Jan 7, 2014 at 2:24 PM, Quentin Colombet <qcolombet at
apple.com>wrote:
> I agree with Andy and Jim.
> Actually, I have prototyped a compiler that does exactly this kind of
> promotion in CodeGenPrepare.
> Basically, I have updated the addressing mode matcher so that it moves a
> sext that is in a way of an addressing mode (i.e., it promotes the operand
> of the sext, let us call this operand def, if it is legal to do so, and
> sign extends the operands of def). When the matcher does not manage to
> absorb more computation after promoting def, it can revert the promotion.
>
> I am currently benchmarking this solution and I’ll update this thread with
> the results.
>
Very cool. Could you share the patch? I can also run some benchmarks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140107/21e7eb9e/attachment.html>

On Jan 7, 2014, at 11:40 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Tue, Jan 7, 2014 at 2:24 PM, Quentin Colombet <qcolombet at
apple.com> wrote:
> I agree with Andy and Jim.
> Actually, I have prototyped a compiler that does exactly this kind of
promotion in CodeGenPrepare.
> Basically, I have updated the addressing mode matcher so that it moves a
sext that is in a way of an addressing mode (i.e., it promotes the operand of
the sext, let us call this operand def, if it is legal to do so, and sign
extends the operands of def). When the matcher does not manage to absorb more
computation after promoting def, it can revert the promotion.
> 
> I am currently benchmarking this solution and I’ll update this thread with
the results.
> 
> Very cool. Could you share the patch? I can also run some benchmarks.
Sure, but be aware that this is a prototype (not structured, not commented) :).
In particular, it is missing the rollback if the promotion does not help

-Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140107/a6133594/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sext_x86.patch
Type: application/octet-stream
Size: 11979 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140107/a6133594/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140107/a6133594/attachment-0001.html>

Hi Chandler,

Here is an updated patch, that I plan to submit for review.
In particular, it has the rollback mechanism when the addressing mode is not
profitable.

Could you run some benchmarks with it?

Thanks,
-Quentin

On Jan 7, 2014, at 11:40 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Tue, Jan 7, 2014 at 2:24 PM, Quentin Colombet <qcolombet at
apple.com> wrote:
> I agree with Andy and Jim.
> Actually, I have prototyped a compiler that does exactly this kind of
promotion in CodeGenPrepare.
> Basically, I have updated the addressing mode matcher so that it moves a
sext that is in a way of an addressing mode (i.e., it promotes the operand of
the sext, let us call this operand def, if it is legal to do so, and sign
extends the operands of def). When the matcher does not manage to absorb more
computation after promoting def, it can revert the promotion.
> 
> I am currently benchmarking this solution and I’ll update this thread with
the results.
> 
> Very cool. Could you share the patch? I can also run some benchmarks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140120/6fd40564/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sext_with_restore_x86.patch
Type: application/octet-stream
Size: 48380 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140120/6fd40564/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140120/6fd40564/attachment-0001.html>

I've not yet looked at the code, but just to give you somewhat raw numbers:

Across all of our benchmarks there was overall change outside of the noise.
There is one benchmark that may have been improved, but I'm not 100%
certain it'll be reproducible as opposed to a fluke run.

While this isn't fantastic news, on the flip side, nothing regressed, so
that's a really good sign. Also, no size regressions to speak of (0.02%?
yea, no one will care).
>From a performance stance I think this patch looks fine if you guys are
seeing significant improvements.


On Mon, Jan 20, 2014 at 11:58 AM, Quentin Colombet <qcolombet at
apple.com>wrote:
> Hi Chandler,
>
> Here is an updated patch, that I plan to submit for review.
> In particular, it has the rollback mechanism when the addressing mode is
> not profitable.
>
> Could you run some benchmarks with it?
>
> Thanks,
> -Quentin
>
>
> On Jan 7, 2014, at 11:40 AM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
>
> On Tue, Jan 7, 2014 at 2:24 PM, Quentin Colombet <qcolombet at
apple.com>wrote:
>
>> I agree with Andy and Jim.
>> Actually, I have prototyped a compiler that does exactly this kind of
>> promotion in CodeGenPrepare.
>> Basically, I have updated the addressing mode matcher so that it moves
a
>> sext that is in a way of an addressing mode (i.e., it promotes the
operand
>> of the sext, let us call this operand def, if it is legal to do so, and
>> sign extends the operands of def). When the matcher does not manage to
>> absorb more computation after promoting def, it can revert the
promotion.
>>
>> I am currently benchmarking this solution and I’ll update this thread
>> with the results.
>>
>
> Very cool. Could you share the patch? I can also run some benchmarks.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140121/2ddf10a8/attachment.html>