[llvm-dev] [RFC] New diagnostic handler for llc

[Krzysztof Parzyszek via llvm-dev]

The errors that clang reports are mostly related to invalid inputs, so 
it helps the user to report as many of them to reduce the number of 
recompilations needed to find all problems.
In case of llc, on the other hand, errors usually indicate some sort of 
a problem with the compiler itself.

The problem is that when we try to recover from an error in the backend, 
the recovery itself could potentially cause further erroneous 
situations.  For example, if you generate an "undef" value for something 
you cannot meaningfully create otherwise, some code down the road may 
assert claiming that it did not expect an "undef" at this point.  That 
may be a completely reasonable assertion, given an assumption that 
invalid input should have been rejected earlier on.

The problem in PR24071 seemed to be that clang proceeded with 
compilation even though the inline asm was not valid.  I'm not sure that 
there is value in trying to make the backend continue compiling code 
that most likely has no meaning.

-Krzysztof


On 5/12/2016 7:20 AM, Diana Picus via llvm-dev wrote:
> Hi all,
>
> I'd like to add a new diagnostic handler to llc. Right now, llc
> doesn't have one at all, and instead just exits after the first error
> that it encounters. This is very different from the behaviour of clang
> and other front ends, who try to report as many errors as possible
> before exiting.
>
> I think this is very important for testing LLVM's CodeGen in a more
> robust fashion. For instance, PR24071, for which I have submitted a
> patch recently [1], would've been uncovered by our current tests,
> instead of being reported by a clang user through a .c file.
>
> I've uploaded a sample patch for the new diagnostic handler on
> Phabricator [2]. With this patch, we currently get 27 failures in
> check-all. 9 of these are PR24071 and would be fixed by patch [1]. The
> other 18 [3] seem to have pretty diverse causes and I don't know if I
> could propose patches for all of them.
>
> What would be a good way forward for this?
>
> I was thinking about leaving the old behaviour, i.e. no diagnostic
> handler, under a flag and running the remaining 18 failures with that
> flag enabled. This would leave all bots green and help us write better
> tests by default. Then we could progressively fix these bugs and get
> rid of the flag. I know people here are a bit wary of such transitions
> that could leave things in between. Is there a better option?
>
> Thanks,
> Diana
>
> [1] http://reviews.llvm.org/D20156
> [2] http://reviews.llvm.org/D20202 - Note that this isn't really a
> review yet, I just thought it looks better there than as a plain
> attachment.
> [3] LLVM :: CodeGen/AMDGPU/call.ll
>      LLVM :: CodeGen/AMDGPU/dynamic_stackalloc.ll
>      LLVM :: CodeGen/AMDGPU/no-hsa-graphics-shaders.ll
>      LLVM :: CodeGen/AMDGPU/private-memory-broken.ll
>      LLVM :: CodeGen/AMDGPU/promote-alloca-bitcast-function.ll
>      LLVM :: CodeGen/ARM/2012-09-25-InlineAsmScalarToVectorConv2.ll
>      LLVM :: CodeGen/BPF/many_args1.ll
>      LLVM :: CodeGen/BPF/many_args2.ll
>      LLVM :: CodeGen/BPF/struct_ret1.ll
>      LLVM :: CodeGen/BPF/struct_ret2.ll
>      LLVM :: CodeGen/MIR/Generic/invalid-jump-table-kind.mir
>      LLVM :: CodeGen/MIR/Generic/llvm-ir-error-reported.mir
>      LLVM :: CodeGen/MIR/Generic/machine-function-missing-function.mir
>      LLVM :: CodeGen/MIR/Generic/machine-function-missing-name.mir
>      LLVM :: CodeGen/MIR/Generic/machine-function-redefinition-error.mir
>      LLVM :: CodeGen/MIR/X86/spill-slot-fixed-stack-object-aliased.mir
>      LLVM :: CodeGen/MIR/X86/spill-slot-fixed-stack-object-immutable.mir
>      LLVM :: CodeGen/MIR/X86/variable-sized-stack-object-size-error.mir
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation