bjorn3 commented on Issue #1191:
I think it was #1113.
abrown commented on Issue #1191:
Why do we want this?
When adding new instructions to Cranelift, I have frequently found errors of the "no encoding found" sort. Sometimes a type is not bound correctly, sometimes a predicate is preventing the compiler from seeing the encoding, sometimes the instruction is in the wrong CPU mode, etc. Looking through the generated Rust code to figure out why no encoding is found is very difficult, mostly because of the lookup table structures. If we could at least see a list of all encodings, their recipes, types, and (eventually) predicates, then we could more quickly troubleshoot the above errors.
I don't have all the information that might be useful in this PR (e.g. predicates) but I was trying to get something in place and then iterate. I am displaying the information I care about--is there something else that should be added? Or is a different format more helpful?
Is there a way we could not generate this by default?
Yes, we could. I like the idea of adding a
clif-util encodings
command to print this information to stdout and then the user can do what they want with it. Does that sound good?
bnjbvr commented on Issue #1191:
I don't have all the information that might be useful in this PR (e.g. predicates) but I was trying to get something in place and then iterate. I am displaying the information I care about--is there something else that should be added? Or is a different format more helpful?
This sounds good as a first iteration!
adding a clif-util encodings command to print this information to stdout and then the user can do what they want with it. Does that sound good?
Sounds good to me too!
abrown commented on Issue #1191:
@bnjbvr, looking at this again today and I realized that if we add a
clif-util encodings
command then we will end up having to write some information out somewhere (a text file, a Rust file, etc.) during the compilation ofcranelift-codegen
. That sort of defeats the purpose of avoiding a compile-time cost so I wanted to confirm we still want to do this. I measured it and when I triedcargo clean && cargo build -p cranelift-codegen -vv
I see a total compile time of ~34s and of that this listing code takes ~14ms. That doesn't seem over-large but we could still put it behind a feature flag for users who may want to disable it, though I would think this would be the type of thing that could be enabled by default.
github-actions[bot] commented on Issue #1191:
Subscribe to Label Action
This issue or pull request has been labeled: "c", "r", "a", "n", "e", "l", "i", "f", "t"
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
github-actions[bot] commented on Issue #1191:
Subscribe to Label Action
This issue or pull request has been labeled: "c", "r", "a", "n", "e", "l", "i", "f", "t"
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
github-actions[bot] commented on Issue #1191:
Subscribe to Label Action
This issue or pull request has been labeled: "cranelift", "cranelift:meta"
<details> <summary>Users Subscribed to "cranelift"</summary>
- @bnjbvr
</details>
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
abrown commented on Issue #1191:
@bnjbvr, thanks for reviewing... but I probably should have closed this: yes, this will likely not be necessary with the new backend. It is solving a problem introduced at the meta-level (e.g. why is cranelift telling me that it can't find an encoding for this instruction?!?) which the new backend may not have. I'll re-open and modify as needed if I am still running into that type of issue once I am a bit more familiar with the new backend.
bjorn3 commented on Issue #1191:
The new backend just uses a big
match
on the instruction. If there is an instruction without encoding, it panics.
Last updated: Nov 22 2024 at 16:03 UTC