Skip to content
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

Closed
pwaller opened this issue Nov 23, 2018 · 4 comments · Fixed by #214 · May be fixed by llir/irutil#1
Closed

Add an Operands() function for inspecting operands of instructions #42

pwaller opened this issue Nov 23, 2018 · 4 comments · Fixed by #214 · May be fixed by llir/irutil#1
Labels
Milestone

Comments

@pwaller
Copy link
Member

pwaller commented Nov 23, 2018

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:

func loopOperands(irModule *ir.Module) {
	for _, f := range irModule.Funcs {
		for _, bb := range f.Blocks {
			for _, i := range bb.Insts {
				log.Println("inst:", i.Def())
				var tmp [16]irvalue.Value
				for _, o := range ir.Operands(tmp[:0], i) {
					log.Println("  op:", o)
				}
			}
		}
	}
}

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 on InstCatchPad and InstCleanupPad. I think if we want to be able to obtain mutable references to Operands, those fields should become of types value.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.

@pwaller
Copy link
Member Author

pwaller commented Nov 23, 2018

@mewmew here's a quick attempt at trivial dead code elimination using this.

https://gist.github.com/pwaller/a2d49c626aa909ecd24ba05b2a96a3c3

@mewmew mewmew added this to the v0.4 milestone Nov 24, 2018
@mewmew
Copy link
Member

mewmew commented Nov 24, 2018

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 Operands? I realize we can't add methods to instructions with this approach, but at least we can use it to figure out the other aspects, such as memory allocations, API usage etc.

My initial thought is that we may want to implement proper support for use-def tracking, and given this, Operands would most likely not be needed for dead-code elimination, as you could simply look up the uses of each function and global, and if they are not used in other functions being used, them simply mark them for removal.

@pwaller
Copy link
Member Author

pwaller commented Nov 24, 2018

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.

@mewmew
Copy link
Member

mewmew commented Nov 25, 2018

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.

@mewmew mewmew added the API label Mar 14, 2019
mewmew added a commit to mewpull/irutil that referenced this issue Dec 21, 2019
… 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.
@mewmew mewmew mentioned this issue Sep 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants