[PATCH] D62319: IR: add 'byval(<ty>)' variant to 'byval' function parameters

Duncan P. N. Exon Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 29 10:08:11 PDT 2019


dexonsmith added inline comments.


================
Comment at: llvm/lib/IR/Attributes.cpp:554
+      if (getKindAsEnum() == AI.getKindAsEnum())
+        return getValueAsType() < AI.getValueAsType();
+      return getKindAsEnum() < AI.getKindAsEnum();
----------------
t.p.northover wrote:
> dblaikie wrote:
> > This being pointer ordering - that means it'll be unstable across runs (which I assume/think none of the other attributes are?) - is that OK?(I don't know if that's OK - it probably is OK)
> I did worry about that, but came to the conclusion it doesn't matter unless the same attribute can appear repeatedly. And I don't think that is possible.
> 
> Even with IntAttributes, I replaced the corresponding comparison with an `llvm_unreachable` and the only thing that broke was a unit test specifically exercising this function.
> 
> So in summary I have no real preference between status quo and `llvm_unreachable`, but don't think it's worth implementing a stable order right now.
> 
> I should probably add some checks to that unittest myself though.
I would prefer `llvm_unreachable` or `report_fatal_error` with a comment saying that comparing on type wouldn't be stable, but is also not possible.  Or, sorting it in an unstable way with comment saying it's illegal, and adding a corresponding verifier error.  Happy with whatever you and David decide though, if you think it's better as is.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62319/new/

https://reviews.llvm.org/D62319





More information about the llvm-commits mailing list