bcardosolopes wrote: > CAN we do anything to our types/variables/etc that force us to do the > bytecode for new things? That is, it would be great if we could just > auto-opt-in everything for the bytecode so we get this for every new thing, > so that we don't regress here.
That'd be cool to have. With the current way bytecode encoding works, we'd still need an encoding to be explicitly added when someone adds a new attr/type, but if we can enforce it, it's already a good step IMO. I'm not too worried about regressions though because the round trip tests will catch changes to existing ones (but I see your point, if we create a new type / attr that raises some existent but expensive one, that could affect the existing size). One idea would be to somehow squeeze the encoding information in the .td defintions of attr / types, so they can live along side the actual definitions. The tablegen classes (CIR_Types, CIR_Attr...) could provide default encoding entries that lead to tablegen failures. It's a bit out-of-scope right now, but I'm willing to give it a try once we wrap up existing attributes and types in CIR - I also have other MLIR changes for mutable types that we'll need for our structs, and probably better to wait on these as prereq before we design this. Let me know if you have extra ideas. https://github.com/llvm/llvm-project/pull/229586 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
