RFR: 8241042: x86_64: Improve Assembler generation

[Claes Redestad]

On 2020-03-16 18:25, Vladimir Kozlov wrote:
> On 3/16/20 8:40 AM, Claes Redestad wrote:
>> Hi,
>>
>> on x64, folding consecutive bytes emitted by Assembler routines into
>> byte-wise variants of emit_int16, emit_int24 and emit_32 turns out to
>> be profitable, since gcc can't seem to fold the back to back stores
>> to the end() pointer into one. The new methods are also a bit
>> convenient.
> 
> Yes, I agree with this.
> 
> Can you put () around arguments like next? It would be easy see them:
> 
> emit_int24((0x44 | regenc), (scale << 6 | indexenc | baseenc), (disp & 
> 0xFF));

Sure.

> 
> Or better put them on separate lines as you did in some cases.

I prefer keeping the expressions more compact, unless there's a need to
comment on what's going on.

> 
> Can we avoid cast (unsigned char) or should we do it always (when sign 
> bit may be set)? I seems we added it to avoid additional instructions 
> generated by gcc.

I did some testing and couldn't see any difference from removing them
on linux, but the Windows compiler starts complaining if you pass a 0x80
or higher literal to a method taking an int8_t. I wonder if there's any
reason to keep these signatures as int8_t and not go with
uint8_t/u_char, and started playing with that. But yeah, this changeset
is already getting a bit out of control so I dialed back a bit.

> 
>>
>> Together with a few other small fixes, this adds up to around a 0.4%
>> reduction in instructions retired on Hello World.
> 
> I wish you did these small fixes as separate RFE. Changes are already big.

Ok. Splitting out the InstructionAttr changes to: 
https://bugs.openjdk.java.net/browse/JDK-8241077

Be right back...

/Claes