This is an archive of the discontinued LLVM Phabricator instance.

llvm-reduce: Avoid invalid attribute reduction on optnone functions
ClosedPublic

Authored by arsenm on Jan 3 2023, 4:58 AM.

Details

Summary

We have this ridiculous restriction that optnone requires noinline,
so the pair needs to be removed if we want to remove noinline.

Diff Detail

Event Timeline

arsenm created this revision.Jan 3 2023, 4:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 3 2023, 4:58 AM
arsenm requested review of this revision.Jan 3 2023, 4:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 3 2023, 4:58 AM
Herald added a subscriber: wdng. · View Herald Transcript

ridiculous restriction

+1

We should not have that. It's super annoying honestly and does not help at all. Nobody would be any worse off if we remove the assertion. Shouldn't we do that?

ridiculous restriction

+1

We should not have that. It's super annoying honestly and does not help at all. Nobody would be any worse off if we remove the assertion. Shouldn't we do that?

Yes but this is an argument I remember losing when optnone was first introduced. optnone cannot be an enforceable semantic and can act like weak noinline on its own

jdoerfert accepted this revision.Jan 3 2023, 11:37 AM

ridiculous restriction

+1

We should not have that. It's super annoying honestly and does not help at all. Nobody would be any worse off if we remove the assertion. Shouldn't we do that?

Yes but this is an argument I remember losing when optnone was first introduced. optnone cannot be an enforceable semantic and can act like weak noinline on its own

I don't understand, though I vaguely remember trying to remove that assertion myself at some point.

If we don't try to do the right thing anymore, this seems to be the least wrong. LG

This revision is now accepted and ready to land.Jan 3 2023, 11:37 AM

ridiculous restriction

+1

We should not have that. It's super annoying honestly and does not help at all. Nobody would be any worse off if we remove the assertion. Shouldn't we do that?

Yes but this is an argument I remember losing when optnone was first introduced. optnone cannot be an enforceable semantic and can act like weak noinline on its own

I don't understand, though I vaguely remember trying to remove that assertion myself at some point.

If we don't try to do the right thing anymore, this seems to be the least wrong. LG

I think this should be fixed, but I don't have the bandwidth to tilt at that particular windmill at the moment. The arguments for this was fear of QoI for some reason. It's presumptive about the implementation, since noinline actually destroys debugging on amdgpu since function debug info is incomplete (particularly upstream)