search for: handleable

...s likely something we'd want separately from a more general purpose solution in any case, as it's analogous to the inline assembler '&' constraint, for example. Do you have specific examples in mind that would be expressible with something more complicated that aren't handleable via an early-clobber constraint? > The grammar would change to something like: > > constraint: operand '!=' operand > | operand '=' operand > > This seems more intuitive and more generally applicable. I could > see a use > for this in other architectur...

...Well, even for the tiny case of J=S=10, this would require a matrix of 10^10 rows, and my little linux machine refuses to cooperate, complaining about allocating a vector of length 1410065408. For these values of J and S, I happen to know that the are 6360 distinct combinations, which is eminently handleable. Anyone got any better ideas? allcomb <- function(J,S){ f <- function(...) { 1:S } out <- as.matrix(do.call("expand.grid", lapply(1:J, FUN = f))) out <- t(apply(out,1,sort)) unique(out) } -- Robin Hankin Uncertainty Analyst National Oceanography...

On Tuesday 15 December 2009 19:52, Jim Grosbach wrote: > Do you have specific examples in mind that would be expressible with > something more complicated that aren't handleable via an early-clobber > constraint? Not offhand, no. I'm mostly concerned about the readability of .td files. > Perhaps spelling it out more fully with "earlyclobber" rather than > "early" would help? That's better. Is there any way you could convince TableG...

On Tuesday 15 December 2009 18:01, Jim Grosbach wrote: > For a usage example, I've included in the patch the modification to > use the constraint for the STREX ARM instruction. Your example is: constraints = "@early $success" Why not spell it as: constraints = "$success != $src", "$success != $ptr" The grammar would change to something like:

All, I've attached a small patch that adds a new early-clobber operand constraint option to TableGen and would like to get feedback before proceding. As background, the ARM store-exclusive instruction (STREX) stores a success result code in a register operand, and that register cannot be the same register as either the source of the value to be stored, or the base address.

Hi Rafael, > What prevents you from using a diag handler in the jit server that > sends errors/warnings over the RPCChannel? What would you do with errors that can't reasonable be serialized when they reach the diagnostic handler? And what would you do with the serialized bytes on the client end? - Lang. Sent from my iPhone On Feb 10, 2016, at 10:31 AM, Rafael Espíndola

On Dec 15, 2009, at 6:26 PM, David Greene wrote: > On Tuesday 15 December 2009 19:52, Jim Grosbach wrote: > >> Do you have specific examples in mind that would be expressible with >> something more complicated that aren't handleable via an early- >> clobber >> constraint? > > Not offhand, no. I'm mostly concerned about the readability of .td > files. > >> Perhaps spelling it out more fully with "earlyclobber" rather than >> "early" would help? > > That's...

Some shaders appear to extract bits using shift/and combos. Detect (some) of those and convert to EXTBF instead. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 66 +++++++++++++++------- 1 file changed, 46 insertions(+), 20 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp

...some > "Serializable" interface and writing their serialization/deserialization > code in the error type itself. The server can then contain a > checkTypedError block that boils down to: > > while (1) { > if (auto Err = handleServerCommand(Channel)) > if (Err is handleable by the server) > /* handle it */ > else if (Err.isA<Serializable>()) > Err->serialize(Channel); /* Report it to the client, let them > respond */ > else > return Err; /* Bail out of the server loop */ > } > > Cheers, > Lang. > >...

...90 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might c...

...90 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might c...

Hi Sanjoy, Thanks for feedback! As for memory effects, currently I use " inaccessiblememonly " for it. It allows to prove that it doesn't alias with any other load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitching).