-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an Operands() function for inspecting operands of instructions #42
Comments
@mewmew here's a quick attempt at trivial dead code elimination using this. https://gist.github.com/pwaller/a2d49c626aa909ecd24ba05b2a96a3c3 |
Marking this with the v0.4 milestone as it pertains to analysis, which is the focus of the v0.4 release. For now, I think we can experiment a bit at a separate repository. @pwaller would you care creating llir/analysis for this purpose and add an initial implementation of My initial thought is that we may want to implement proper support for use-def tracking, and given this, |
I'll hold off on doing this for now. I'd prefer to avoid (myself) putting something in the llir namespace until it's closer to an API we want to support. |
Sounds good. We can continue to experiment until, and of course keep open discussions until we get closer to something that may be generally usable and a good API for data flow analysis. |
… update API Rather than adding the use-tracking to llir/llvm/ir, we currently add this to irutil so we may get more experience with the API and see if its the right fit for instruction and terminator operand use-tracking and value update. Note: this is the stronger version of the API, as outlined by @pwaller in llir/llvm#42 (comment) Notably, operands are tracked by pointer (*value.Value) which also enables updating values using the same API. Fixes llir/llvm#42.
I think it would be very useful to have a way of finding the operands of an instruction.
Here's an example of a code generator which makes such a function.
https://gist.github.com/pwaller/255654cd78b77484a02cdfaa6a22237c
In the end, I don't know exactly how I feel about it (especially the code generation part...).
But I guess this gets me quite close to being able to implement a simple dead code pass which can kill unused private functions.
Example use:
I note that Operands() could almost return pointers to values, so that the references were mutable. However, this is broken. The only reason it is broken that I can find is the
Scope
field onInstCatchPad
andInstCleanupPad
. I think if we want to be able to obtain mutable references to Operands, those fields should become of typesvalue.Value
. I guess there are pros and cons to that. But if you want mutable references to operands I think the alternatives are going to be much uglier.The text was updated successfully, but these errors were encountered: