[PATCH] x86: move ginsn stuff

[Indu Bhagat]

On 7/29/24 12:30 AM, Jan Beulich wrote:
> On 27.07.2024 09:35, Indu Bhagat wrote:
>> On 7/26/24 6:31 AM, Jan Beulich wrote:
>>> This had been badly inserted between md_assemble() and its helpers
>>> anyway. Follow what was done for Arm64 and move the code to its own
>>> file, #include-d as appropriate.
>>
>> Thanks for moving the code to tc-i386-ginsn.c.  I agree its cleaner that
>> way.
>>
>> But moving the sframe related APIs to "tc-i386-ginsn.c" is confusing.  I
>> think we should continue to keep the sframe related code in tc-i386.c.
> 
> Well, I can certainly leave the sframe functions where they were. To me they
> just look more connected to ginsn than anything else.
> 
>>> ---
>>> I would want to exclude all of this code when !BFD64, i.e. when 64-bit
>>> code can't be emitted in the first place. However, the common files are
>>> always built, even on architectures entirely unlikely to ever gain
>>> ginsn / sframe support. I think that would need sorting first.
>>>
>>
>> gas/gen-sframe.c is built but has checks inside, e.g., #ifdef
>> support_sframe_p, so only the backends opting in for SFrame support have
>> the functionality compiled in.
>>
>> gas/sframe-opt.c does get compiled in every time, true.
>>
>> Even for SCFI/ginsn generic files, there should be checks for
>> TARGET_USE_GINSN or TARGET_USE_SCFI, so that backends not opting for
>> these functionalities do not have stuff compiled in.
>>
>> So, IIUC, checking for !BFD64 will be a finer grain check and will
>> further limit some of the above code for only cases when host is 64-bit
>> or when a 64-bit target is involved.  Right ?
> 
> Yes, that's more fine-grained and x86-only.
> 

OK. Later if there are any more use-cases of ginsn other than SCFI for 
x86, it should easy to enable ginsn for a wider set of targets by 
rolling back these checks again.

Thanks