RFR: 8204331: AArch64: fix CAS not embedded in normal graph error
Andrew Haley
aph at redhat.com
Fri Jun 22 08:09:03 UTC 2018
On 06/21/2018 03:20 PM, Andrew Dinn wrote:
> There are currently no proper tests for this code as it was difficult to
> know how to identify what code gets generated. Detection of failures is
> left to asserts in the predicates. That approach has worked in the
> present case but only after a breaking change has been pushed and only
> by detecting one of several breaking changes. So the current regime is
> rather fragile. It would be good to have some jtreg tests to help detect
> breakages like this more quickly and effectively.
>
> A slowdebug build with an available hsdis-aarch64.so could be used to
> print out generated assembly. Usefully, in debug mode the C2 back end
> will print out block comments indicating both where membars have been
> placed and where they have been elided. If a jtreg test was run in an
> otherjvm with CompileCommand options to compile and print target methods
> then the output could be scanned to look for the relevant membar/membar
> elided comments and for presence or absence of ldar/stlr and ldaxr/stlxr
> instructions. This would be enough to test that basic transformations
> are sound.
>
> Is it possible to rely on an hsdis library being available in jtreg
> tests? Alternatively, is it possible to make execution of the test
> conditional on the library being present?
Here's an idea: we could scan the generated code. We could also annotate
the assembler so that it asserted that all ldar/stlr were generated. We
could certainly do that even in a product build. If your tests force C2
compilation and disable inlining we can make the tests repeatable.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-dev
mailing list