We already have a similar simplification facility in SValBuilder created to solve the similar problem with iterator checkers. It fires up when it knows that the values it works with are limited to roughly 1/4 of their type's range and therefore none of the individual operations over them can potentially overflow (cf. D35109). It's currently off by default because performance was not properly evaluated and none of the on-by-default checkers rely on it. This is currently the intended approach to such issues. It was decided that constructing a custom solver for "non-overflowing but still bounded" arithmetic was not the right thing to do, mostly because it absolutely doesn't correspond to the actual run-time behavior of the program that we're supposed to be modeling.
I experimented a bit more and came up with another alternative: allow VPValue to model 3 different things: 1) concrete VPValues, 2) sub VPValues and 3) virtual VPValue: D88380
Managing those 3 in VPValue directly simplifies things further down a bit and I put up 2 more follow-on patches that turn VPReciepBase into a VPValue (D88379) and then also a VPUser (D88378). The last one also contains a unit test that looks upwards & downwards along the def-use chains. Note that we should probably move most/all remaining recipes to be VPValues and manage operands as VPUser before the last 2 patches.
Overall this probably results in a simpler structure overall. If we want, we could then also fold VPUser into VPRecipeBase.
I'm not convinced this should be necessary - although it does seem to show some missed opportunities in truncateVectorWithPACK because we bail if the destination vector size < 64 bits - fixing that would avoid many of ISD::TRUCATION cases in ReplaceNodeResults
whats is its can anyone explain why I receiving it
Please upload with full context
Addresses the review comments.
Adds an extra test case to test whether the proper overload is called. The proper overload is a bit of a surprise so when the expected behaviour changes the overload test can be adjusted.
Needs a rebase.
In what situation do we generate mustprogress function attributes now? I was expecting them in clang/test/CodeGen/attr-mustprogress.cpp but did not see any.
We need new tests specifically for this. Using the maxobjsize attribute especially
LGTM. I think this is the right way to handle this. the size can be partially undef (="non-deterministic & variable") but everything else better is not.
Thanks for sharing. As mentioned earlier, the main reason at the moment is to ensure a step-by-step transition and once all recipes are migrated the common class can be hoisted to VPRecipeBase. I hope the explanation makes sense.
Like I said I'm happy that we are moving towards the ability to do this better. It will be good to see VPlan being able to start to make some real improvements! If we are happy enough with this way of doing things, at least currently, then I can go and make some more sensibly sized patches :)
I've updated the patch to continue to reject attributes on anonymous bit-fields, but with a better diagnostic. In addition, I changed how we handle anonymous bit-fields with an initializer (based on discussion on the Core reflector) -- instead of rejecting the construct as a semantic issue, I reject it at the parser level with a similar diagnostic (I went with "in-class initializer" because that's used by other parser diagnostics, but I'm fine with either formulation).
LGTM as long as this is not too expensive in terms of compile-time, thanks!
LGTM, thanks. Suggestion inline, but quite subjective, so feel free to ignore.
This also doesn't work on my macOS system:
FAIL: LLDB (/Users/teemperor/1llvm/rel/bin/clang-x86_64) :: test_stop_hooks_scripted_return_false (TestStopHookScripted.TestStopHooks) ====================================================================== FAIL: test_stop_hooks_scripted_return_false (TestStopHookScripted.TestStopHooks) Test that the returning False from a stop hook works ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/teemperor/1llvm/llvm-project/lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py", line 54, in test_stop_hooks_scripted_return_false self.do_test_auto_continue(True) File "/Users/teemperor/1llvm/llvm-project/lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py", line 91, in do_test_auto_continue self.assertEqual("main", func_name, "Didn't stop at the expected function.") AssertionError: 'main' != 'step_out_of_me' - main+ step_out_of_me : Didn't stop at the expected function. Config=x86_64-/Users/teemperor/1llvm/rel/bin/clang ----------------------------------------------------------------------
Done. Thanks for the patch!
Rebase after D88225.
@teemperor Thanks for the quick review and context!
I don't have commit access, that'd be great if you could merge it in.
To clarify the description a bit: RegInfoBasedABI::GetRegisterInfoByName is comparing the name/alt_name by doing a const char * pointer value comparison. That only works if both strings that are compared are coming from a ConstString. Since b0060c3a7868ef026d95d0cf8a076791ef74f474 GetRegisterInfoByName is checking with an assert that both C strings came from a ConstString (which is failing as these ABI implementation changed here are lacking the ConstString'ification code).
Thanks for adding NPM support! Not sure if all tests should be also updated to add NPM run-lines.
rename wouldOptimize to ReuseFrameSlot.
Hi Jim, this change broke my Fedora 33 Linux (x86) box. Do you think we can get a quick fix or revert this?
code format fix
Use the FlagInserter mechanism in SelectionDAGBuilder::visitFCmp.
Remove Flags from getSetcc which was previously added for SelectionDAGBuilder.
Thanks, LGTM! Please, give some time for @ftynse to have a look.