search for: vscale_var

...y). In some sense, if you make vscale dynamic, you've introduced dependent types into LLVM's type system, but you've done it in an implicit manner. It's not clear to me that works. If we need dependent types, then an explicit dependence seems better. (e.g., <scalable <n> x %vscale_var x <type>>) 2. How would the function-call boundary work? Does the function itself have intrinsics that change the vscale? If so, then it's not clear that the function-call boundary makes sense unless you prevent inlining. If you prevent inlining, when does that decision get made? Will...

...e dynamic, >> you've introduced dependent types into LLVM's type system, but you've >> done it in an implicit manner. It's not clear to me that works. If we >> need dependent types, then an explicit dependence seems better. (e.g., >> <scalable <n> x %vscale_var x <type>>) > That's a shift from the current proposal and I think we can think > about it after the current changes. For now, both SVE and RISC-V are > proposing function boundaries for changes in vscale. I understand. I'm afraid that the function-boundary idea doesn'...

On 31 July 2018 at 21:10, David A. Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi David, >> >> Let me put the last two comments up: >> >>> > But we're trying to represent slightly different techniques >>> > (predication, vscale change) which need