RFR: 8276563: Undefined Behaviour in class Assembler

Thomas Stuefe stuefe at openjdk.java.net
Tue Nov 9 06:03:36 UTC 2021


On Mon, 8 Nov 2021 16:38:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Okay, I'd assume not having the encoding be `const` would be fine, as long as `Register` is passed around by-value. i.e. only some code's private copy of a `Register` instance would be overwritten (same as if it was a pointer).
> > Any ways, thanks for trying this out! If the required changes are too much (making backporting harder as well) I think going with a more focused fix is the way to go, as well. Maybe we can come back for a broader refactoring another day.
> 
> Sorry, my last comment was a bit misleading. I should not have posted so soon. I have something that works now with a bunch of overloads and `constexpr` references, etc., but it's all a bit too much.

I thought some more about this, and so far like your first approach (using an array, and maybe not subtracting but ANDing) best.

Its a pity that piggybacking on "this" is UB since it is exactly what one wants here.

I know this is probably not what you want, but I just mention it: how about making Register a plain type (e.g. int)? We could replace calls to `r->encoding` and `r->value()` with just `r`. Then, to add functionality and to group it nicely, make todays Register subclasses utility wrappers which wrap around such an Register. You'd have to create those things on the fly when you need them, but at least the compiler would optimze them away.

I know that would mean a ton of changes. But it would be exactly what you want to express, would not be UB, would be portable and easy to understand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6280


More information about the hotspot-compiler-dev mailing list