Page MenuHomePhabricator

[NFC] Include short string attributes in the "Function Attrs" comment
AbandonedPublic

Authored by jdoerfert on Jun 1 2019, 1:13 PM.

Details

Summary

So far, the comment above a function in LLVM-IR did not include any
string function attributes. While for many of them it is preferable not
to have them there, sometimes it makes sense. This patch introduces a
heuristic based on the size of the string attribute name and value.
If they together do not contain more than 15 characters we include them
in the comment, otherwise we do not.

Event Timeline

jdoerfert created this revision.Jun 1 2019, 1:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 1 2019, 1:13 PM
rnk added a comment.Jun 3 2019, 11:41 AM

I'd be in favor of this.

@rnk Should I take that as a LGTM or do you have another person in mind that should take a look?

pcc added a comment.Jun 3 2019, 6:55 PM

This change seems kind of arbitrary to me. Not all attributes that we might want to test for are shorter than 15 characters. Some are already longer and they can't be changed because of bitcode compatibility.

If the goal is to make things involving attributes more easily testable, why not work towards that goal directly? For example, you could add a flag that means "print all attribute names/values in the comment" and then use that in your tests.

In D62784#1528498, @pcc wrote:

This change seems kind of arbitrary to me. Not all attributes that we might want to test for are shorter than 15 characters. Some are already longer and they can't be changed because of bitcode compatibility.

While I guess we could introduce short names for existing long attributes, I agree with the general premise, this is "kind of arbitrary". Though, we talk about printing comments and what we do now is arguably "kind of arbitrary" as well. If you feel that it is not a good idea to print more arguments in the comment, I will not do it.

If the goal is to make things involving attributes more easily testable, why not work towards that goal directly? For example, you could add a flag that means "print all attribute names/values in the comment" and then use that in your tests.

I did want to avoid that because we easily have 15+ attributes and new ones are added fairly often. That means testing for all of them is not a good option. Now testing for a subset is hard, especially if you want to ensure some attributes to be there and others to be absent. The way I would write it, potentially not the best way though, would involve multiple interleaved check and check-not lines.

pcc added a comment.Jun 5 2019, 11:17 AM
In D62784#1528498, @pcc wrote:

This change seems kind of arbitrary to me. Not all attributes that we might want to test for are shorter than 15 characters. Some are already longer and they can't be changed because of bitcode compatibility.

While I guess we could introduce short names for existing long attributes, I agree with the general premise, this is "kind of arbitrary". Though, we talk about printing comments and what we do now is arguably "kind of arbitrary" as well. If you feel that it is not a good idea to print more arguments in the comment, I will not do it.

If the goal is to make things involving attributes more easily testable, why not work towards that goal directly? For example, you could add a flag that means "print all attribute names/values in the comment" and then use that in your tests.

I did want to avoid that because we easily have 15+ attributes and new ones are added fairly often. That means testing for all of them is not a good option. Now testing for a subset is hard, especially if you want to ensure some attributes to be there and others to be absent. The way I would write it, potentially not the best way though, would involve multiple interleaved check and check-not lines.

Maybe you could sort the attributes by name before printing? Then e.g. if you want to check for presence of "a" and "c" and the absence of "b" you could do

CHECK: "a"
CHECK-NOT: "b"
CHECK: "c"

And it wouldn't matter which other attributes are printed.

In D62784#1531329, @pcc wrote:
In D62784#1528498, @pcc wrote:

This change seems kind of arbitrary to me. Not all attributes that we might want to test for are shorter than 15 characters. Some are already longer and they can't be changed because of bitcode compatibility.

While I guess we could introduce short names for existing long attributes, I agree with the general premise, this is "kind of arbitrary". Though, we talk about printing comments and what we do now is arguably "kind of arbitrary" as well. If you feel that it is not a good idea to print more arguments in the comment, I will not do it.

If the goal is to make things involving attributes more easily testable, why not work towards that goal directly? For example, you could add a flag that means "print all attribute names/values in the comment" and then use that in your tests.

I did want to avoid that because we easily have 15+ attributes and new ones are added fairly often. That means testing for all of them is not a good option. Now testing for a subset is hard, especially if you want to ensure some attributes to be there and others to be absent. The way I would write it, potentially not the best way though, would involve multiple interleaved check and check-not lines.

Maybe you could sort the attributes by name before printing? Then e.g. if you want to check for presence of "a" and "c" and the absence of "b" you could do

CHECK: "a"
CHECK-NOT: "b"
CHECK: "c"

And it wouldn't matter which other attributes are printed.

I agree this would be possible but I'm not sure if it'll be better than what we have now and worth the effort. My solution did break 4 existing tests that add arguments that should not exist in the first place (not included in the patch because I saw them only after a rebase yesterday). I expect the change you propose to cause a lot of breakages. I'll think about it and either update the patch or abandon it.

@pcc So I thought about this. I don't think printing all attributes always helps. Testing for a single "Function Attrs" line will be very brittle, the use of multiple check lines will make tests harder to read/write/maintain and the IR output is cluttered. What if we have an output like this one under a flag? It would have all the benefits this patch has and, as you seem to dislike it, it would be on an opt-in basis. Though, I'm still unsure under which circumstance this patch would be worse than the status quo.

jdoerfert abandoned this revision.Jun 12 2019, 11:06 PM

I give up on this for now. If there is interest in this we can revive it later.