https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #6)
> (In reply to Kewen Lin from comment #3)
> > The motivation of this request is to try our best to make power10 attributed
> > code inline more power8/power9 attribute code which likely includes some
> > inline asm but not HTM related as the quoted OSS shows. For now, for one
> > function which has any non-empty inline asm string, we would consider it's
> > possible to have HTM code so it's unsafe to inline it.
> 
> We've hit this issue (attempting to inline some Power8/9 function into a
> Power10 caller) before with another project (I forget which) and the
> solution used was to add no-htm to the attribute target options (ie,
> "cpu=power8,no-htm").

Yes, I agree that we already have some solutions for that, no-htm option or
no-htm,htm target option attributes. I was thinking unrealistically if we don't
have to teach users about these things (or sometimes users even don't notice
this). But as you pointed out, the inline asm parsing approach looks
impractical.

> 
> > Users usually think higher cpu attributed code can safely inline lower cpu
> > attributed code, but it's out of expectation for power10 code inlining
> > power8/power9 code as we drops HTM from power10. If we can support it
> > better, users don't need more extra efforts to teach about it.
> 
> Ideally, we could just go back in time and not enable HTM by default on
> Power8/9 and force the user to always use -mhtm if they need HTM support. 
> That ship has sailed though.

Florian Weimer raised this point in PR102059, the compatibility was the concern
though, no further comments/discussions on this then. :(

> 
> That said, I think nearly all (all?) HTM usage on Power uses our HTM
> built-in functions.  Maybe we could remove OPTION_MASK_HTM from the
> power8/power9 default flags and only add it back in if we detect the use of
> an HTM built-in function?
>
> Looking at GLIBC, Power's elision-lock.c use of our htm.h uses inline asm
> with HTM instructions and not our HTM built-in functions and it doesn't
> explicitly add -mhtm to the command line options like S390 does, so I think
> this idea won't work. :-(

Thanks for checking!  Sigh...

Reply via email to