search for: reaaaally

Hi Bjoern, Did you see my previous reply? There's no way to do this currently. ORC assumes you know all the symbols, > since you added the modules defining them. > For testing / debugging you can dump the modules to stderr using > ExecutionSession::dump, but that's about it. > Do you want the symbols for diagnostic purposes, or some other reason? Regards, Lang. On Mon, Aug

...t is where my question came from. > > However… I’m a bit worried about taking symbols from modules, because some > of the symbols might change later when the code was compiled with the JIT. > So I felt like that the ExecutionSession would been more reliable. > > > > But if I reaaaally want such a function, I could basically have a look > into the dump function… Cause I think my motivation is not convincing xD > > > > Thank you Lang! > > > > Kind greetings > > Björn > > > > > > *From:* Lang Hames <lhames at gmail.com> >...

...d for vectorisation. it becomes impossible to set vscale to 4, which another function might have been specifically designed to use. so what would then need to be done is: predicate out the top 4 elements, which now comes with a performance-penalty and a whole boat-load of mess. so, apologies: we reaaaally need vscale to be selectable on at the very least a per-function basis. otherwise, applications would have to set it (at runtime) to the "least inconvenient" value, wasting "the least-inconvenient number of registers". > The scalable type tells you the maximum number of el...

On Tue, Oct 1, 2019 at 8:08 AM Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hello Jacob and Luke, > > First off, even if a dynamically changing vscale was truly necessary > for RVV or SV, this thread would be far too late to raise the question. > That vscale is constant -- that the number of elements in a scalable > vector does not change during program execution