ojhunt wrote: > > Ok, so one thing I see in the tests is a similar issue to what I've been > > looking at while prepping the tmo feature - the tests are essentially > > "random looking number". We've had regressions in the past as a result of > > the tests being essentially opaque - I'm unsure if it's worth you > > addressing this here as I'll be looking to address it while upstreaming the > > tmo functionality in which case we're just duplicating effort. > > Only the constexpr tests (previous PRs in the series) do test the hashes, > simply because of there no being intermediate testable step. But for CodeGen > (here) we can actually test the !alloc_token intermediate metadata before > that is turned into a hash.
Sorry I was unclear - the problem we've found is the seemingly random nature of the hash has meant people accept whatever change has occurred. I guess in this case they are considered to be completely random hashes - the TMO random looking numbers include semantic flags which means the tests check for explicit values, but there's no reasonable way for someone to understand if some random looking change in the giant random looking number is a correct random looking change to a random looking number. I'm playing with the tmo behavior to see if I can make something more useful/meaningfully testable - an ideal solution would be a test only builtin that produced a human readable string, but that would make people very very sad :D https://github.com/llvm/llvm-project/pull/156842 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
