This is an archive of the discontinued LLVM Phabricator instance.

Introduce the AttributeMask class
ClosedPublic

Authored by serge-sans-paille on Dec 21 2021, 7:18 AM.

Details

Summary

This class is solely used as a lightweight and clean way to build a set of
attributes to be removed from an AttrBuilder. Previously AttrBuilder was used
both for building and removing, which introduced odd situation like creation of
Attribute with dummy value because the only relevant part was the attribute
kind.

Diff Detail

Event Timeline

serge-sans-paille requested review of this revision.Dec 21 2021, 7:18 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptDec 21 2021, 7:18 AM
nikic added inline comments.Dec 21 2021, 7:46 AM
llvm/include/llvm/IR/Attributes.h
1015

This assert doesn't make sense to me. AttributeMask doesn't accept arguments.

1052

Should this check TargetDepAttrs as well?

1053

This looks inverted. Isn't this the implementation of empty()?

1054

to -> from

nikic added a comment.Dec 21 2021, 8:00 AM

Pre-merge checks also report a build failure in llvm/lib/Target/AMDGPU/AMDGPURewriteOutArguments.cpp:360.

remvove useless assert, update comment, fix build

serge-sans-paille marked 2 inline comments as done.
serge-sans-paille added inline comments.
llvm/include/llvm/IR/Attributes.h
1052

I matched the implementation in AttrBuilder, which looks odd to me too.

nikic added inline comments.Dec 21 2021, 8:54 AM
llvm/include/llvm/IR/Attributes.h
1051

Shouldn't this be ||?

1052

Where is the method used? Can we just drop it?

Remove empty() method and only keep hasAttributes

nikic accepted this revision.Dec 21 2021, 12:13 PM
nikic added a reviewer: aeubanks.

This looks good to me, but I'd recommend waiting a bit before landing in case there's further input, as this is a non-trivial API change.

I think separating AttrBuilder (which stores attribute keys and values) from AttributeMask (which only stores keys) makes sense conceptually. With the current API, it's not really obvious that the attribute values are completely ignored for removal operations -- on the surface it looks like the attribute would only get removed if both key and value match, but that's not how it actually works.

This should also give more flexibility in optimizing AttrBuilder for it's primary use case (which is adding attributes).

This revision is now accepted and ready to land.Dec 21 2021, 12:13 PM

This looks good to me, but I'd recommend waiting a bit before landing in case there's further input, as this is a non-trivial API change.

(Maybe valuable to start a quick thread on llvm-dev to get more eyes on this? (I'm not suggesting that's required, just pointing out the option...))

I think separating AttrBuilder (which stores attribute keys and values) from AttributeMask (which only stores keys) makes sense conceptually. With the current API, it's not really obvious that the attribute values are completely ignored for removal operations -- on the surface it looks like the attribute would only get removed if both key and value match, but that's not how it actually works.

This should also give more flexibility in optimizing AttrBuilder for it's primary use case (which is adding attributes).

FWIW, I agree that this approach seems good. (SGTM, not LGTM, only because I haven't reviewed the patch details.)

nikic added a comment.Dec 22 2021, 1:08 AM

Looking at some of the changes here, I landed a couple of cleanup commits:

I think the latter change should allow you to drop the AttrMask::hasAttributes() method from the API.

rebased on main branch

This revision was landed with ongoing or failed builds.Jan 4 2022, 6:40 AM
This revision was automatically updated to reflect the committed changes.