[llvm] r214011 - [x86] Fix PR20355 (for real). There are many layers to this bug.

Quentin Colombet qcolombet at apple.com
Wed Aug 13 16:50:06 PDT 2014


Hi Chandler, hi Ben,

I haven’t been able to come up with a test case that uses the low part of MUL_LOHI, even with Ben’s suggestion.

The questions now are:
1. Do we leave the code as is and wait for it to fail?
or
2. Do we fix the mask as I think Ben, You, and I agree that this is wrong?

I would prefer #2, though #1 would give us a test case when it eventually fails!

What do you think?

Thanks,
-Quentin

On Aug 5, 2014, at 10:28 AM, Quentin Colombet <qcolombet at apple.com> wrote:

> Thanks Ben!
> 
> I’ll see if I can expose the bug with that approach.
> 
> -Quentin
> 
>> On Aug 5, 2014, at 2:02 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:
>> 
>> On Mon, Aug 4, 2014 at 7:48 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>>> Ping?
>>> 
>>> Benjamin, any idea on how we can write a test for the lowering of the low
>>> part of the MUL_LOHI on x86?
>> 
>> The only way I can think of is having a wide mul in IR and let the
>> legalizer emit a MUL_LOHI. I don't know what magic incantation is
>> needed for that though :/
>> 
>> - Ben
>> 
>>> 
>>> Thanks,
>>> -Quentin
>>> 
>>> On Jul 29, 2014, at 9:22 AM, Quentin Colombet <qcolombet at apple.com> wrote:
>>> 
>>> 
>>> On Jul 28, 2014, at 2:21 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>>> 
>>> 
>>> On Jul 28, 2014, at 12:58 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>>> 
>>> 
>>> On Mon, Jul 28, 2014 at 12:46 PM, Quentin Colombet <qcolombet at apple.com>
>>> wrote:
>>>> 
>>>> I think we still have a bug in the current implementation.
>>>> See my inline comments.
>>> 
>>> 
>>> Seems likely. Can you craft a test case to demonstrate it?
>>> 
>>> 
>>> I will see if I can come up with something.
>>> 
>>> 
>>> I haven’t found anything yet. The case I know that was using this path (div
>>> -> mul) just uses the high part of the result. Thus, the problem does not
>>> show up.
>>> 
>>> CC’ed Benjamin, he may have an idea on how to test that.
>>> 
>>> Cheers,
>>> -Quentin
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> Also, I think it would be nice to update the comments on the masks value
>>>> instead of removing them.
>>>> When I reversed engineered this code, it took me ages to figure out what
>>>> were these magic values.
>>> 
>>> 
>>> I'm not sure that's going to help. The problem with comments is that they
>>> can get out of sync. I also don't think that little endian offsets are
>>> surprising or need lots of clarification here? The 1 instead of 0 thing you
>>> point out screams wrong to me at a glance, and I don't think a comment would
>>> really make it better (or worse, unless it got out of date).
>>> 
>>> 
>>> Fair enough!
>>> 
>>> -Quentin
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>>> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits





More information about the llvm-commits mailing list