search for: sizeless

...should still work. Allocas of scalable vectors are supported, and it's only later at codegen that the unknown sizes result in more work being needed to compute stack offsets correctly. The caveat being that a direct call to something like getTypeStoreSize() will need to be aware of expressions/sizeless-types. If however these passes are exclusively using allocas to put registers into memory, or using structs with extractvalue etc, then they shouldn't need to care and codegen deals with the low level details. Thanks, Amara

[Sending again to list] Hi Chris, Responses inline... On 6 July 2017 at 21:02, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for sending this out Graham. Here are some comments: > > This is a clever approach to unifying the two concepts, and I think that the approach is basically reasonable. The primary problem that this will introduce is: >

...revent the same filter from being used multiple times in IGraphBuilder_Connect(). rpcrt4: Handle absense of RPC flags in call_stubless_func() thunk. wined3d: Implement depth bias clamp. d3d10core/tests: Add depth bias clamp tests. widl: Allow all dimensions of an array to be sizeless. widl: Check for positive array dimension when parsing array. widl: Remove dead code. widl: The default pointer attribute for an array is always ref. widl: Properly handle nesting of pointers and arrays when parsing. widl: Correctly generate headers for nested arrays a...

...d answer. > > It's worth noting that we don't expect the last case (mixed scaled and > unscaled sizes) to occur. Richard Sandiford's proposed C extensions > (http://lists.llvm.org/pipermail/cfe-dev/2018-May/057830.html) explicitly > prohibits mixing fixed-size types into sizeless struct. > > I don't know if we need a 'maybe' or 'unknown' result for cases comparing scaled > vs. unscaled; I believe the gcc implementation of SVE allows for such > results, but that supports a generic polynomial length representation. > > My current intent...

...at we don't expect the last case (mixed > scaled and > > unscaled sizes) to occur. Richard Sandiford's proposed C extensions > > (http://lists.llvm.org/pipermail/cfe-dev/2018-May/057830.html) > explicitly > > prohibits mixing fixed-size types into sizeless struct. > > > > I don't know if we need a 'maybe' or 'unknown' result for cases > comparing scaled > > vs. unscaled; I believe the gcc implementation of SVE allows for > such > > results, but that supports a generic polynomia...

...od answer. > > It's worth noting that we don't expect the last case (mixed scaled and > unscaled sizes) to occur. Richard Sandiford's proposed C extensions > (http://lists.llvm.org/pipermail/cfe-dev/2018-May/057830.html) explicitly > prohibits mixing fixed-size types into sizeless struct. > > I don't know if we need a 'maybe' or 'unknown' result for cases comparing scaled > vs. unscaled; I believe the gcc implementation of SVE allows for such > results, but that supports a generic polynomial length representation. > > My current intentio...

Hi, Now that Sander has committed enough MC support for SVE, here's an updated RFC for variable length vector support with a set of 14 patches (listed at the end) to demonstrate code generation for SVE using the extensions proposed in the RFC. I have some ideas about how to support RISC-V's upcoming extension alongside SVE; I'll send an email with some additional comments on