In D150262#4584618, @hctim wrote:

Peter's out of office. This patch looks fine to me, and I'll land it for you.

ok, I can land it too, no worries.

@pcc Do you mind to land this?
chromium run into this recently: https://bugs.chromium.org/p/chromium/issues/detail?id=1454613

@peter.smith & @MaskRay Thanks for the comments, patch is updated.
Moved the example to a bug.

minimised reproducer (crashes on a BTI enabled system without the patch, work with the patch)

Ping @pcc

LGTM

LGTM

@efriedma Thanks!
Rebased.

LGTM, thanks!

I'd add note to the documentation too when scalable vectors are used the sleef library is expect to be compiled with it.

ping

Thanks!

Last version fixes the Chromium and others crashes. Generic solution for CloneModule is conceptually more complex and probably orthogonal to this change.

let's remove ifuncs if not used.

In D144982#4171702, @tejohnson wrote:

In D144982#4170950, @danielkiss wrote:

In D144982#4169480, @tejohnson wrote:

I'm a little confused - did we create an illegal split module by cloning the ifunc to the regular LTO split module? Should the handling in CloneModule (particularly with its use of the ShouldCloneDefinition callback) be changed so that ifunc are not cloned if their resolver is not cloned?

simplifyExternals turns the resolver to external. Externals won't be in the module summary which will be referenced by the ifunc.

Right, simplifyExternals ensures that any symbols cloned into the merged Module as declarations are either dropped if there are no references or made external if there are. But this is not specific to resolver functions.

Ah, I see that the latest version of the patch has moved the new ifunc handling into simplifyExternals, and only drops the ifunc if the resolver func is not defined in the module. This is better as it isn't unconditional.

What I was asking was whether we can handle this directly in CloneModule via the callback, instead of removing the ifunc later. I.e. should CloneModule be changed to invoke ShouldCloneDefinition on the ifunc resolver function before deciding whether to clone over each ifunc definition? Because it generally seems incorrect to create a module with an ifunc with a resolver function not defined in that module (i.e. not just when splitting the ThinLTO module, but any time we invoke CloneModule with a callback that doesn't simply return true for everything).

LGTM

In D144982#4169480, @tejohnson wrote:

I'm a little confused - did we create an illegal split module by cloning the ifunc to the regular LTO split module? Should the handling in CloneModule (particularly with its use of the ShouldCloneDefinition callback) be changed so that ifunc are not cloned if their resolver is not cloned?

simplifyExternals turns the resolver to external. Externals won't be in the module summary which will be referenced by the ifunc.

LGTM Thanks

clean up createTLII since now fronted checks for the target support.

Thanks for the patch. LGTM.

In D134719#4048366, @duplexsystem wrote:

Is there any chance of enabling this on platforms other than AArch64? Sleef has x86, AArch32, PowerPC64, System/390, CUDA, and WebAssembly support (although I am mostly interested in x86), in addition to AArch64.

I'll look into adding x86, x86_64, probably in new patch top of this. I would add targets where we have demand.

Linux kernel sets the the BT0 (and BT1) to 1 unconditionally.
This results the When the PE is executing at EL0, PACIASP and PACIBSP are not compatible with PSTATE.BTYPE == 0b11. (ArmARM)
That means PACI*SP is just a BTI C from BTI point of view.

jut a NIT, LGTM otherwise.

ping

just small comment, thanks @ilinpv
LGTM, just let others to chime in.

Wondering if we could deduplicate the headers?

address review comments, added more tests. rebased.

LGTM.

LGTM to enable this on Arm/AArch64.

LGTM

adding test

ping

update docs.

To accommodate better to the vector ABI, AAPCS the vector parameter registers are not preserved by the callee but save the whole vector registers.

MTE/TME parts are removed, they will get their own patch.