On Feb 28, 2011, at 9:47 AM, Andrew Clinton wrote:> This looks like a good extension to the type system. One thing that I > expected to work (when I first tried using opaque types) was for the > optimization passes and verification to operate correctly when using > opaque types, while the type could be made concrete later on - after > optimization. This turned out to be impossible, and in combination with > the lack of naming for opaque types, I decided to avoid their use > entirely. In particular, could you address whether this overhaul of the > type system will address the following: > > - The ability to create constants for named types without a defined > structureThere is no change, this won't be allowed.> - Optimization involving PHI nodes for named types without a defined > structureNot sure what you mean here, but I don't anticipate any change.> - The ability to pass in named types to external function call arguments > and return valuesThis is representable in the IR, but will blow up at codegen time, just like today.> Basically, I'd like to be able to construct valid programs involving > named types (without a defined structure), optimize/verify them, and > then provide a structure for the type later on.I don't expect this series of changes to meaningfully impact this usage scenario, sorry! -Chris
On 02/28/2011 04:00 PM, Chris Lattner wrote:>> - Optimization involving PHI nodes for named types without a defined >> structure > Not sure what you mean here, but I don't anticipate any change. >I thinking along the lines of conversion to select instructions, and elimination of PHIs with identical incoming values - SSA-based transformations that are currently valid for concrete types.>> - The ability to pass in named types to external function call arguments >> and return values > This is representable in the IR, but will blow up at codegen time, just like today. >I'm not sure what you mean. Code generation requires concrete types, so it would still be necessary to specify the structure for all types before code generation time. Last time I checked, it's not currently possible to pass opaque types to external functions and have a valid IR - this currently fails in the verifier. It is possible to pass pointers to opaque types, though.>> Basically, I'd like to be able to construct valid programs involving >> named types (without a defined structure), optimize/verify them, and >> then provide a structure for the type later on. > I don't expect this series of changes to meaningfully impact this usage scenario, sorry! > > -ChrisMy two cents are that this is a useful usage scenario to consider if any major changes are being made to the type system. A ton of meaningful optimizations can be performed without requiring concrete types, and it would provide a nice interface for type system extension (without making core changes to the IR). Andrew
On Feb 28, 2011, at 3:42 PM, Andrew Clinton wrote:>>> >>> Basically, I'd like to be able to construct valid programs involving >>> named types (without a defined structure), optimize/verify them, and >>> then provide a structure for the type later on. >> I don't expect this series of changes to meaningfully impact this usage scenario, sorry! >> >> -Chris > > My two cents are that this is a useful usage scenario to consider if any > major changes are being made to the type system. A ton of meaningful > optimizations can be performed without requiring concrete types, and it > would provide a nice interface for type system extension (without making > core changes to the IR).Sure, I'm just saying that it is orthogonal to the set of problems that I'm looking to solve. I'm not opposed to someone else making this happen. -Chris