[llvm-dev] Testing "normal" cross-compilers versus GPU backends

[Krzysztof Parzyszek via llvm-dev]

The Hexagon compiler (that we ship) only comes as a cross-compiler, and 
we don't include any other targets in it.  We set the default target 
triple to hexagon-..., and the "make check" works.  (I think we may have 
had to XFAIL some tests, but it was not widespread.)

The problem in the AMDGPU case seems to be that there are some features 
that the backed does not support (will not support?), and any test that 
relies on them will fail.  In theory, each target could have a 
corresponding set of limitations, and that set could be different for 
each such target.  The theoretical solution would then be to identify 
the set of all features and annotate each test (that does not specify 
the target triple) to list all the required ones.  Each target could 
mark some features as "unsupported" and then only the fully supported 
tests would run.  In practice this is a lot of work and I have no idea 
if this problem is common enough to warrant it.

If this is specific to AMDGPU, then maybe the solution could also be 
specific?  For example, the tests that are not expected to work on that 
target could just be XFAILed with a comment explaining it.  It's ugly, 
but it's quick.

-Krzysztof


On 9/2/2015 7:44 PM, Robinson, Paul via llvm-dev wrote:
> This note arose from http://reviews.llvm.org/D12506 but the reviewers
> felt that we needed a broader audience, because the proposed patch
> really didn't solve the entire problem and we had no better ideas.
>
> Mehdi Amini needs to build LLVM with just a GPU backend, and still have
> "ninja check" Just Work.  Commits r243958-243960 tried to accomplish
> that; however they are too big a hammer, and cause much simpler cross
> environments (like mine) to exclude big chunks of very useful tests
> (including my favorite, DebugInfo).
>
> FYI, my main cross environment is building on X86 Windows but using
> a default target triple for PS4 (which is also X86).
>
> I experimented with building LLVM with just the ARM backend (running on
> an X86 workstation) and setting the default triple to some ARM value.
> "ninja check" worked fine (without Mehdi's series of commits), so the
> normal kind of cross-compiler environment seems to be happy with how
> things were set up originally.
>
> Mehdi reports building LLVM with the X86 and AMDGPU backends, setting
> the default triple to "amdgcn--amdhsa", and getting 200-some failures.
>
> (This does make me wonder about AMDGPU testing in general; how does that
> work?  The only places I see lit checks for AMDGPU are in the usual
> target-dependent places.)
>
>
> Mehdi's solution was:
> - In lit.cfg, change the existing "native" feature definition from
>    "host-triple == target-triple" to also check "and the corresponding
>    backend is included."(**)
> - Make piles of tests that seemed inapplicable to GPUs depend on the
>    "native" feature (through REQUIRES: or in the lit.local.cfg).
> - Build LLVM with just the GPU backend, and not set a target triple
>    (i.e., it's set to the host triple, typically an X86-something).(*)
>    Thus lit.cfg sees matching host and target triples, but the X86
>    backend is missing, and so the "native" feature is not set.
>
> [The "native" feature was invented to identify environments where
> JIT would work properly. The "host-triple == target-triple" condition
> isn't exactly right, but it works well enough.]
>
> The major problem is that these new "native" dependencies are incorrect.
> For example the DebugInfo tests don't really require it; they work fine
> as long as the default triple has the corresponding backend included,
> as my ARM-on-X86 experiment demonstrated.
>
> So, we need some solution that Mehdi can use in a GPU-backend-testing
> workflow, but that does not so drastically interfere with normal
> cross-compiler testing.  Does anybody have any suggestions?
>
> Thanks,
> --paulr
>
>
> (*) This configuration seems inherently wrong; the default target triple
> ought to require having the corresponding backend included, I think.
> (**) Which makes this modification superfluous.
>
> _______________________________________________
> 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