Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

[David Edelsohn <dje dot gcc at gmail dot com>]

On Tue, Feb 6, 2018 at 10:43 AM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On 2/6/18 6:42 AM, Peter Bergner wrote:
>> On 2/5/18 10:48 PM, David Edelsohn wrote:
>>> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
>>>> I did also try calling expand_divmod() here which did generate correct
>>>> code, the problem was that it wasn't as clean/optimized as the change
>>>> to gen_divdi3.
>>>
>>> Why not fix it at the site of the call to gen_divdi3 instead of the
>>> divdi3 pattern?
>>
>> Well as I said above, I did try that and we got worse code.  That said,
>> I unconditionally called expand_divmod() instead of calling gen_divdi3()
>> when we can (TARGET_POWERPC64).  Let me retry with that change and see
>> what kind of code gen we get.
>
> Ok, calling expand_divmod() in the !TARGET_POWERPC64 case still generates
> worse code.  However, if I instead explicitly generate the call to the
> div/udiv lib functions, then I seem to get the same code as the gen_*
> patch gave...at least for my unit tests I've been using.  Let me
> bootstrap/regtest the following, which I assume you're more happy with?

Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR
iterator, as Segher suggested?

Otherwise, this seems like the more correct approach to not conflict
with the semantics expected by the patterns.

We'll see what Segher has to say.

Thanks, David