This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Detemplate PltSection<ELFT> section.
AbandonedPublic

Authored by grimar on Mar 16 2017, 6:22 AM.

Details

Reviewers
ruiu
rafael
Summary

Deemplating PltSection opens road for detemplating
SymbolBody::getVA() method which depends on
getPltVA() currently, which is easy to detemplate after this change.
That opens way to detemplate other parts of linker.

Diff Detail

Event Timeline

grimar created this revision.Mar 16 2017, 6:22 AM
grimar edited the summary of this revision. (Show Details)Mar 16 2017, 6:24 AM
grimar edited the summary of this revision. (Show Details)Mar 16 2017, 6:30 AM
ruiu edited edge metadata.Mar 16 2017, 3:49 PM

This doesn't seem like an improvement. The new code look more complicated than the original one. Maybe you want to make these classes non-template classes, while keeping some member functions template?

In D31028#703332, @ruiu wrote:

This doesn't seem like an improvement. The new code look more complicated than the original one. Maybe you want to make these classes non-template classes, while keeping some member functions template?

I think it is.

I tried keeping single template method for PltSection in D30982. It also works for what I want to do finally, so committed it as rL298065;
But this patch not more complicated in my opinion. See original code:

In<ELFT>::Plt->addEntry<ELFT>(Body);
In<ELFT>::GotPlt->addEntry(Body);
In<ELFT>::RelaPlt->addReloc({Target->PltRel, In<ELFT>::GotPlt,
                             Body.getGotPltOffset(), !Preemptible,
                             &Body, 0});

Does it clear that Plt->addEntry depends on RelaPlt->addReloc ? If you switch their order code will be broken, because
Plt->addEntry inside refers to offset of relocation in RelaPlt.
Change made in this patch reveals this dependency making it explicit. I think that is itself simplifies logic.

ruiu added a comment.Mar 17 2017, 9:26 AM

So you submitted a modified version of this patch as r298065? As a common practice, once you sent a patch for review, you are supposed to wait for an LGTM (if you think that a new patch is obvious, you can submit it to let other people do post-commit review, but it needs to be actually obvious and shouldn't be waiting for an LGTM). I appreciate your recent cleanup commits, but you want to slow down a bit here to follow the rule.

In D31028#703875, @ruiu wrote:

So you submitted a modified version of this patch as r298065? As a common practice, once you sent a patch for review, you are supposed to wait for an LGTM (if you think that a new patch is obvious, you can submit it to let other people do post-commit review, but it needs to be actually obvious and shouldn't be waiting for an LGTM). I appreciate your recent cleanup commits, but you want to slow down a bit here to follow the rule.

Not modified version of this patch, but a patch that changes nothing and just removes templating, leaving the single method templated. It is obvious trivial change I think.
And I kept this patch on review because think it is better way and can be committed on top.

Do you think https://reviews.llvm.org/rL298065 really needed pre-commit review ?

ruiu added a comment.Mar 17 2017, 9:48 AM

So you submitted a modified version of this patch as r298065? As a common practice, once you sent a patch for review, you are supposed to wait for an LGTM (if you think that a new patch is obvious, you can submit it to let other people do post-commit review, but it needs to be actually obvious and shouldn't be waiting for an LGTM). I appreciate your recent cleanup commits, but you want to slow down a bit here to follow the rule.

Not modified version of this patch, but a patch that changes nothing and just removes templating, leaving the single method templated. It is obvious trivial change I think.
And I kept this patch on review because think it is better way and can be committed on top.

Do you think https://reviews.llvm.org/rL298065 really needed pre-commit review ?

No, r298065 is a modified version of this patch. I suggested doing the thing this patch is attempting to to do in a different way, and r298065 is an implementation of the suggestion. In general, if you get a comment to do a thing in a different way, the new patch to do in the new way is a continuation of the original patch. If my code review were slow, I could have understood, but you are actually getting very fast code review from me every day, so no need to haste that much, right? Please allow me to review your patches.

In D31028#703910, @ruiu wrote:

So you submitted a modified version of this patch as r298065? As a common practice, once you sent a patch for review, you are supposed to wait for an LGTM (if you think that a new patch is obvious, you can submit it to let other people do post-commit review, but it needs to be actually obvious and shouldn't be waiting for an LGTM). I appreciate your recent cleanup commits, but you want to slow down a bit here to follow the rule.

Not modified version of this patch, but a patch that changes nothing and just removes templating, leaving the single method templated. It is obvious trivial change I think.
And I kept this patch on review because think it is better way and can be committed on top.

Do you think https://reviews.llvm.org/rL298065 really needed pre-commit review ?

No, r298065 is a modified version of this patch. I suggested doing the thing this patch is attempting to to do in a different way, and r298065 is an implementation of the suggestion. In general, if you get a comment to do a thing in a different way, the new patch to do in the new way is a continuation of the original patch. If my code review were slow, I could have understood, but you are actually getting very fast code review from me every day, so no need to haste that much, right? Please allow me to review your patches.

I just asked. For me it was trivial thing, I did not think it needs review. First time I did the same what r298065 does in D30982, that was earlier than your suggestion.
Sorry, I will push things on review next time then.

grimar abandoned this revision.Mar 30 2017, 1:29 AM