search for: unmodel

Hi A bunch of instructions that I have defined in tablegen files get tagged with unmodeledSideEffect property. I have defined these instructions with no corresponding dag patterns. Is there a way i can avoid this property and say they do not have any side effects thanks shrey

...t; > I'm not sure what is the semantics of "hasSideEffects" at the MI level. I'm surprised we can consider correct that something that writes to memory is not "having side effects". Answer to myself, I finally found the MI API (thanks Matthias), and it is called hasUnmodeledSideEffects. I think the "unmodeled" part of the name is important here :) Here is the doxygen: /// \brief Return true if this instruction has side /// effects that are not modeled by other flags. This does not return true /// for instructions whose effects are captured by: ///...

...s is pretty clearly undesirable behavior for > CL, even if it may (or may not) be technically permitted by the C > specification. I’d be in favor of clarifying our definition of > noalias to disallow this transformation. So we're specifically talking about intrinsics tagged as having unmodeled side effects? Or arbitrary functions? -Hal > > —Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Hal Finkel Assistant...

...be relatively easy to have the intrinsics > serve as code-motion barriers for other code that might be threads > sensitive (like other external function calls), we would need to think > through exactly how this would work. The easiest thing would be to make > the intrinsics have having unmodeled side effects, although we might > want to do something more intelligent. Yes, that's exactly the idea. > Where do you propose placing the parallel loop intrinsics calls > relative to the loop code? In preloop ("opening" intrinsic) and postloop ("closing" one)....

...de that might be > > > threads > > > sensitive (like other external function calls), we would need to > > > think > > > through exactly how this would work. The easiest thing would be > > > to > > > make > > > the intrinsics have having unmodeled side effects, although we > > > might > > > want to do something more intelligent. > > > > Yes, that's exactly the idea. > > Right. You should verify that using the 'unmodeled side effects' tag > does not inhibit the optimizations you seek to p...

...cs > > serve as code-motion barriers for other code that might be threads > > sensitive (like other external function calls), we would need to > > think > > through exactly how this would work. The easiest thing would be to > > make > > the intrinsics have having unmodeled side effects, although we > > might > > want to do something more intelligent. > > Yes, that's exactly the idea. Right. You should verify that using the 'unmodeled side effects' tag does not inhibit the optimizations you seek to preserve. If we need to work out som...

...desirable behavior for >> CL, even if it may (or may not) be technically permitted by the C >> specification. I’d be in favor of clarifying our definition of >> noalias to disallow this transformation. > > So we're specifically talking about intrinsics tagged as having unmodeled side effects? Or arbitrary functions? We don't have such a tag for intrinsics to my knowledge. -Owen > -Hal > >> >> —Owen >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm....

...t; > threads >> > > sensitive (like other external function calls), we would need to >> > > think >> > > through exactly how this would work. The easiest thing would be >> > > to >> > > make >> > > the intrinsics have having unmodeled side effects, although we >> > > might >> > > want to do something more intelligent. >> > >> > Yes, that's exactly the idea. >> >> Right. You should verify that using the 'unmodeled side effects' tag >> does not inhibit the o...

...rich Weigand wrote: > C) Floating-point exceptions > If a mask bit in the floating-point status register is set, then all FP > instructions will *trap* whenever an IEEE exception condition is > recognized. This means that we need to treat those instructions as > having unmodelled side effects, so that they cannot be speculatively > executed. Also, we cannot schedule FP instructions across instructions Does this mean that the problems with the default expansion of ISD::FP_TO_UINT would be solved by the backend knowing that it should model traps? In D43515 the issu...

Hello all, I want to add a custom intrinsic to the LLVM IR which would be lowered into a pseudo instruction since it doesn't correspond to any real instruction defined by the architecture. The speciality of this intrinsic/pseudo instruction that it should behave like a scheduling barrier: every instruction before the intrinsic has to be emitted before the intrinsic, the same goes for all

...an't quite figure out how to do it), but I don't see any references to situations such as age, edu, and age*edu . For the article, we used Bugs, which is fine, but I'd like to see how far I can take it using lmer. I could kludge it by, for example, including age, edu, and region as unmodeled factors: lmer (y ~ black*female + (1 | state) + factor(region) + factor(age) + factor(edu) + (1 | age.edu), family=binomial(link="logit")) but I'd like to do the full multilevel version. Thanks! Andrew -- Andrew Gelman Professor, Department of Statistics Professor, Department...

...desirable behavior for >> CL, even if it may (or may not) be technically permitted by the C >> specification. I’d be in favor of clarifying our definition of >> noalias to disallow this transformation. > > So we're specifically talking about intrinsics tagged as having unmodeled side effects? Or arbitrary functions? Arbitrary functions calls can contain barriers ( in CL) or thread joins (in C), so I think the same reasoning had to apply to them as well. -Owen > -Hal > >> >> —Owen >> _______________________________________________ >> LL...

...9;s at least makes control flow well-defined. Adding "volatile" to every IR load and store instruction, including accesses to local variables, seems terrible for both optimization and correctness. Our handling of setjmp is already a complete mess; I don't want to add another way for unmodeled control flow to break code. (See also http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt, for a proposal to make invoke less messy.) -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Ten Tzen via llvm-dev Se...

...enceable while > the other is? In other words, does dereferenceability depend on > the addrspace of the pointer given that the "location" is > dereferenceable? In our architecture, address space casts will never trap and are deterministic (unless there is some asm with unmodelled side effects). However, there are pointers that can be dereferenced in one address space but not another: speculatively performing the load would be a real bug. Ideally, this would be a target-specific decision, but having the default be to not propagate the dereferencing information and allow...

...that we should be using implicit control register dependencies, which will at least prevent moving floating-point operations across instructions that e.g. change rounding modes. However, the main property we need to model is that floating-point operations may *trap*. I guess this can be done using UnmodeledSideEffects, but I'm not quite clear on how to make this dependent on whether or not a "strict" operation is requested (without duplicating all the instruction patterns ...). Once we do use something like UnmodeledSideEffects, I think MachineIR passes should handle everything correc...

...less restricted "write-through" concept for memory access inside a _try. But I think the benefit of it is minor and it's not worth it as the amount of code directly under _try is very small, and usually is not performance critical code. ? ..I don't want to add another way for unmodeled control flow to break code. I would really love to hear (and find a way to improve) if there is any place in this design & implementation which is not sound or robust. Thanks, --Ten From: Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>> Sent: Wednesday, A...

Hi all, I'm a grad student from MIT and as part of my thesis, I will be propagating parallelism in the IR level. I will be modifying clang and adding LLVM IR metadata annotations to indicate parallel regions and loops, then write optimizer passes that will run on top of the annotated LLVM IR. There has been a lot of research lately on Parallel IRs, such as SPIR[1

...the result is now safe but maybe not optimal -- which can be improved upon over time by teaching the specific semantics of those intrinsics to optimization passes. However, some open questions remain. If at some point we want to model the constrained FP semantics more precisely than just as "unmodeled side effects", this may have to be reflected at the IR level directly. For example, to model rounding mode behavior, at some point we might require explicit tracking of data dependencies on the rounding mode by representing the rounding mode as SSA values defined by function calls and used...

On 2011-06-26, at 8:44 AM, Jakob Stoklund Olesen wrote: > On Jun 25, 2011, at 11:39 PM, Cameron Zwarich wrote: > >> Someone hit a bug (not in bugs.llvm.org) caused by the non-Darwin call instructions not being marked as using the frame pointer. Is it safe to just add r11 / r7 as uses to the appropriate instructions like we do on Darwin? Does anyone care about the slight pessimization

...aybe not optimal > -- which can be improved upon over time by teaching the specific > semantics of those intrinsics to optimization passes. > > However, some open questions remain. If at some point we want > to model the constrained FP semantics more precisely than just > as "unmodeled side effects", this may have to be reflected at > the IR level directly. For example, to model rounding mode > behavior, at some point we might require explicit tracking of > data dependencies on the rounding mode by representing the > rounding mode as SSA values defined by funct...