llvm dev - Mar 2017 - BZ12772. Can't reproduce in tree. How could it be fixed?

Hi,

What should I do if I cannot trigger a failure in any of the in-tree
targets?

Specifically, bug (https://bugs.llvm.org//show_bug.cgi?id=12772) was raised
back in 2012 with a proposed patch but no test case. I've put a couple of
hours into trying to demonstrate the bug in tree but have not been
successful. The bugzilla suggests the the patch works on three out of tree
targets and that others have similarly failed to produce an in tree repro.
Applying the patch causes no existing tests to fail.

This isn't a problem in that I'll just mark CONCAT_VECTORS as legal in
our
back end.

What is the usual strategy for dealing with bugs in untested code where is
has proven uneconomic to trigger a bug in an upstream back end? For
example, would it be worth converting the patch from 2012 into a
phabricator diff and seeking feedback there?

Kind regards,

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170301/8a82b654/attachment.html>

On 3/1/2017 3:46 PM, Jon Chesterfield via llvm-dev
wrote:
> Hi,
>
> What should I do if I cannot trigger a failure in any of the in-tree 
> targets?
>
> Specifically, bug (https://bugs.llvm.org//show_bug.cgi?id=12772) was 
> raised back in 2012 with a proposed patch but no test case. I've put a 
> couple of hours into trying to demonstrate the bug in tree but have 
> not been successful. The bugzilla suggests the the patch works on 
> three out of tree targets and that others have similarly failed to 
> produce an in tree repro. Applying the patch causes no existing tests 
> to fail.
>
> This isn't a problem in that I'll just mark CONCAT_VECTORS as legal
in
> our back end.
>
> What is the usual strategy for dealing with bugs in untested code 
> where is has proven uneconomic to trigger a bug in an upstream back 
> end? For example, would it be worth converting the patch from 2012 
> into a phabricator diff and seeking feedback there?
>
There are in-tree targets with multiple legal vector types (off the top 
of my head, x86, ARM, Aarch64).  None of those targets have 
CONCAT_VECTORS set to EXPAND, though; the vector registers overlap, so 
there's generally some cheaper way to implement CONCAT_VECTORS.

You could just delete the broken code, I guess?  That wouldn't really 
solve the problem, but at least it would cause a selection failure 
rather than silently miscompiling.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project