This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Simplify a SymbolBody interface a bit.
ClosedPublic

Authored by grimar on Mar 4 2016, 1:56 AM.

Details

Summary

I think we can get rid of few accessors in that class, and replace
them with direct field access.

Positive features from that are (just an IMHO of course):

  • Use of direct fields instead of accessor is more readable as you can never know the exact logic of accessor when looking on it (will it just return the pre-ready result or has some condition).
  • Code generally is a bit shorter (please refer to the patch code).
  • Less methods in interfaces.
  • Currently 2 bitfields *probably* consume less memory than single int8 (that depends on structures aligment I think and I did not look close on difference for this patch). Also looks like we will not need any other flags, but even if we will, I think 1-2 new bitfields is probably more preferable than 1-2 new methods because of profits mentioned above.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar updated this revision to Diff 49804.Mar 4 2016, 1:56 AM
grimar retitled this revision from to [ELF] - Simplify a SymbolBody interface a bit..
grimar updated this object.
grimar added reviewers: davide, emaste, rafael, ruiu.
grimar added subscribers: llvm-commits, grimar.
rafael edited edge metadata.Mar 4 2016, 5:40 AM
rafael added a subscriber: rafael.

maybe just wait and see the bug Davide was referring to in the other
patch? (some symbols not getting a STT_OBJECT).

Cheers,
Rafael

grimar added a comment.Mar 4 2016, 5:42 AM

maybe just wait and see the bug Davide was referring to in the other
patch? (some symbols not getting a STT_OBJECT).

Cheers,
Rafael

Do you mean this http://reviews.llvm.org/D17876 ? Then its aleady abandoned.

grimar added a comment.Mar 4 2016, 6:03 AM

grimar added a comment.

In http://reviews.llvm.org/D17879#367958, @rafael wrote:

maybe just wait and see the bug Davide was referring to in the other
patch? (some symbols not getting a STT_OBJECT).

Cheers,
Rafael

Do you mean this http://reviews.llvm.org/D17876 ? Then its aleady abandoned.

Looks like it.

Davide, was that the one you were referring to?

Cheers,
Rafael

Actually my patch is closer to this: http://reviews.llvm.org/D17871.
It modifies it and introduces another way to do the same.

George.

davide edited edge metadata.Mar 4 2016, 9:29 AM

I'm not entirely convinced this is a big win honestly. ELF has already a type field we can just leave untouched. isTLS() member function is pretty self-explicative. Maybe if you feel is not it can be renamed to isTlsType() but I don't think that's really required. Still, you have to look at how it's set somewhere in the code to understand.
Also, accessing the field directly rather than hiding the information behind a member function, I'm not a huge fan of that either.
That said, if others like this approach better, I have no strong objections against it.

davide added a comment.Mar 4 2016, 9:31 AM

Also, about the bit field consumes less memory, I'm note entirely sure of that given the current layout. I sort of feel it like a premature'ish optimization. If Symbolbody turns out to be too big then we can reconsider the whole layout to make it smaller. Also, Type is per-se less than 8 bits, so you can apply your proposed optimization to my field as well.

ruiu accepted this revision.Mar 4 2016, 11:11 AM
ruiu edited edge metadata.

LGTM

I don't have a strong preference here, and this patch doesn't reduce the size of SymbolBody (it remains 48 bytes on 64-bit), but if I had written it I would have do that way, so go for it.

This revision is now accepted and ready to land.Mar 4 2016, 11:11 AM
rafael accepted this revision.Mar 4 2016, 11:50 AM
rafael edited edge metadata.

I also have a small preference for it.

The reason being that if we don't need the generality of an arbitrary Type, not storing makes it clear that it is not used.

This revision was automatically updated to reflect the committed changes.