llvm dev - Aug 2015 - [RFC] Improving integer divide optimization (related to D12082)

> On Aug 20, 2015, at 10:22 AM, escha <escha at apple.com> wrote:
> 
>> 
>> On Aug 20, 2015, at 9:59 AM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> 
>>> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com
<mailto:steve at metrokings.com>> wrote:
>>> 
>>> On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at
apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>>> 
>>>> Isn’t the problem the fact that the patch makes it harder for a
target to
>>>> get the generic code to reach its custom hook?
>>>> Now the "cheap pow2 sdiv” is merged with the generic
“cheap div” you can’t
>>>> distinguish anymore.
>>>> 
>>> 
>>> Yes and also the issue of needing more information to make a smart
>>> isIntDivCheap() decision.
>>> 
>>> In visitSDIV(), checking looks like this when the denominator is a
power of 2.
>>> 
>>>   if (TLI.isIntDivCheap(N->getValueType(0), MinSize))
>>>     return SDValue();
>>> 
>>>   // Target-specific implementation of sdiv x, pow2.
>>>   if (SDValue Res = BuildSDIVPow2(N))
>>>     return Res;
>>> 
>>> How about this for isIntDivCheap?
>>> 1) pass Function* to allow the target to decide for itself which
>>> attributes matter, and
>> 
>> If you want the attributes, I think you should pass the attributes and
not the whole Function.
>> 
>> I’m not sure why MinSize does not trigger with -Os by default, Michael
is it intended?
> 
> I think -Oz might be MinSize?  -Oz being absolute minimum size at the cost
of significant speed, IIRC.
Sure, the question is more what is the tradeoff for -Os.
My remember of -Os is somehow “don’t perform transformation that increases code
size”.
It seems that it is what is done here: converting an (possibly expensive)
division into multiple (less expensive) operations, probably increasing code
size (target dependent admittedly).

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150820/534c1415/attachment-0001.html>

The way I understand -Os is “don’t increase size unless there’s a clear and
significant performance gain” – that is, much less aggressive in terms of code
size than the definition you gave below.
I’m not advocating this point of view, mind you, it’s just that this has been my
understanding.

Since leaving the div as-is can be very expensive compared to the alternative
sequence, I thought -Oz was the safe way to go with this.


From: Mehdi Amini [mailto:mehdi.amini at apple.com]
Sent: Thursday, August 20, 2015 20:32
To: escha
Cc: Steve King; llvm-dev; Kuperstein, Michael M
Subject: Re: [llvm-dev] [RFC] Improving integer divide optimization (related to
D12082)


On Aug 20, 2015, at 10:22 AM, escha <escha at apple.com<mailto:escha at
apple.com>> wrote:


On Aug 20, 2015, at 9:59 AM, Mehdi Amini <mehdi.amini at
apple.com<mailto:mehdi.amini at apple.com>> wrote:


On Aug 20, 2015, at 9:46 AM, Steve King <steve at
metrokings.com<mailto:steve at metrokings.com>> wrote:

On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at
apple.com<mailto:mehdi.amini at apple.com>> wrote:


Isn’t the problem the fact that the patch makes it harder for a target to
get the generic code to reach its custom hook?
Now the "cheap pow2 sdiv” is merged with the generic “cheap div” you can’t
distinguish anymore.

Yes and also the issue of needing more information to make a smart
isIntDivCheap() decision.

In visitSDIV(), checking looks like this when the denominator is a power of 2.

  if (TLI.isIntDivCheap(N->getValueType(0), MinSize))
    return SDValue();

  // Target-specific implementation of sdiv x, pow2.
  if (SDValue Res = BuildSDIVPow2(N))
    return Res;

How about this for isIntDivCheap?
1) pass Function* to allow the target to decide for itself which
attributes matter, and

If you want the attributes, I think you should pass the attributes and not the
whole Function.

I’m not sure why MinSize does not trigger with -Os by default, Michael is it
intended?

I think -Oz might be MinSize?  -Oz being absolute minimum size at the cost of
significant speed, IIRC.

Sure, the question is more what is the tradeoff for -Os.
My remember of -Os is somehow “don’t perform transformation that increases code
size”.
It seems that it is what is done here: converting an (possibly expensive)
division into multiple (less expensive) operations, probably increasing code
size (target dependent admittedly).

—
Mehdi

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150823/3ddf1533/attachment-0001.html>

On Sun, Aug 23, 2015 at 12:34 AM, Kuperstein, Michael M
<michael.m.kuperstein at intel.com> wrote:
> The way I understand -Os is “don’t increase size unless there’s a clear and
> significant performance gain” – that is, much less aggressive in terms of
> code size than the definition you gave below.
>
> Since leaving the div as-is can be very expensive compared to the
> alternative sequence, I thought -Oz was the safe way to go with this.
>
Sounds reasonable and the proposed patch keeps -Oz the default.