search for: effecty

I'm trying to replace SDIvRem (whch returns two i16 types) with a custom that returns i32 or i16. I am getting the Assertion (!Node || ResNo < Node->getNumValues() && "Invalid result number for the given node!") Seems that it doesn't like returning one value but how do you return more than one value? I am doing this in the LowerOperation for the case SDIVREM and a

This problem was reported to me by a friend who has an LLVM port that is not put back to open source. Essentially, there is an intrinsic call _lr which is a load register. so then user code has something like: start_time = _lr(TIMER_REGISTER) ..... some_code_to_time .... end_time = _lr(TIMER_REGISTER) So what happens is that LLVM moves the code as follows: start_time = _lr(TIMER_REGISTER)

Hi All, I would like to ask a question on fixed and random effecti in lme. I am fiddlying around Mick Crawley dataset "rats" : http://www.bio.ic.ac.uk/research/mjcraw/statcomp/data/ The advantage is that most work is already done in Crawley's book (page 361 onwards) so I can check what I am doing. I am tryg to reproduce the nested analysis on page 368:

I realized that the rails command could be used very effectiely for non RoR apps, and, with a little tweaking, even nonRuby apps. Anyone give this a try? -- Posted via http://www.ruby-forum.com/.

...be some way to do this I would think. Tia. Reed On 02/21/2014 11:24 AM, Tim Northover wrote: > Hi Reed, > >> How would this intrinsic be implemented properly in llvm so this cannot >> happen? > At the intrinsic level, you'd make sure @llvm.whatever had the most > side-effecty definition possible (I think it's actually the default: > "this may read or write completely random memory wherever it feels > like"). > > At the instruction level, you'd make sure hasSideEffects=1 was set. > > Theoretically, a completely side-effect-free sequenc...

...> more like std::optional. In the long term std::optional is going to > replace llvm::Optional. How bad would that be for your use case? It's not bad, there's other options. I'd be more worried about that change subtly breaking existing usages. The use case is objects with side-effecty destructors that should only run once when the "real" object is moved. MakeCleanup <https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/lib/gtl/cleanup.h> is the archetype here. my options are: a) wrap the object in optional - this requires the "moved = None&q...

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,