search for: downcast

I was looking at "trunc" to downcast a signed integer, say sint32 to sint16, but it seems to handle unsigned integers only. How do you downcast a signed integer? P.S. This question is for my "Mapping High-Level Constructs to LLVM IR" document :-) -- Mikael -------------- next part -------------- An HTML attachment was sc...

Hello > I was looking at "trunc" to downcast a signed integer, say sint32 to sint16, > but it seems to handle unsigned integers only. No. In twos-complement notation (which LLVM assumes) there no difference between signed and unsigned truncation - you just throw out the spare sign bits and that's all. Please note that that the "n...

...resent the "list.end()" iterator. - The way to do this efficiently and safely is to have the sentinel be some un-templated "list_node_base" class that has a next and prev pointer. The next/prev pointers point to "list_node_base", and "list_iterator<T>" downcasts to "T" on dereference. - However, ilist<T> assumes the sentinel is a full-bodied "T" and uses "T*" for the "next" pointers. In practice consumers override the sentinel traits so that the sentinel is only a "ilist_half_node" (to save space)....

...converted into a non-nullable type via an if-test. So for example if x is nullable, and I test x != NULL, then inside the conditional block the type of x is no longer nullable. Nullable types behave slightly differently (and produce less efficient code) than non-nullable types. For example, a downcast to a nullable type is a dynamic cast (because if the cast fails, the result can be NULL), whereas a downcast to a non-nullable type throws an exception if the cast fails. This kind of analysis is trivial given LLVM's architecture. The problem I have, however, is that all of the high-level t...

...00, Waiman Long wrote: > The cpu argument in the function prototype of vcpu_is_preempted() > is changed from int to long. That makes it easier to provide a better > optimized assembly version of that function. > > For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the > downcast from long to int is not a problem as vCPU number won't exceed > 32 bits. > Note that because of the cast in PVOP_CALL_ARG1() this patch is pointless. Then again, it doesn't seem to affect code generation, so why not. Takes away the reliance on that weird cast.

...00, Waiman Long wrote: > The cpu argument in the function prototype of vcpu_is_preempted() > is changed from int to long. That makes it easier to provide a better > optimized assembly version of that function. > > For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the > downcast from long to int is not a problem as vCPU number won't exceed > 32 bits. > Note that because of the cast in PVOP_CALL_ARG1() this patch is pointless. Then again, it doesn't seem to affect code generation, so why not. Takes away the reliance on that weird cast.

...if-test. So for example if x > is nullable, and I test x != NULL, then inside the conditional block > the > type of x is no longer nullable. Makes sense. > Nullable types behave slightly > differently (and produce less efficient code) than non-nullable types. > For example, a downcast to a nullable type is a dynamic cast > (because if > the cast fails, the result can be NULL), whereas a downcast to a > non-nullable type throws an exception if the cast fails. Sure. > This kind of analysis is trivial given LLVM's architecture. The > problem > I have, ho...

...wer 6 bits we could also propagate this change backwards to reduce the bitwidth of prior instructions. I'm synthesizing hardware from LLVM IR so these non-standard bitwidths can actually save chip area. I've started writing a pass to do this but I figured there might be an existing pass for downcasting 64-bit operations to 32-bit operations that I could borrow code from. Thanks, Andrew

...l of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases are simple. Is InstCombine pretty good about finding most/all such cases? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150417/04cee200/attachment.html>

...struct ilist_iterator_base { > ilist_node_base *N; > }; > template <typename NodeTy> > class ilist_iterator : private ilist_iterator_base { > operator pointer() const { return static_cast<NodeTy *>(N); } > }; > -- > This kind of (implicit and potentially UB) downcast makes me uneasy. > > However, this will still be an improvement from having such implicit > (and totally wrong) downcasts on `operator++()`, so maybe it's not a > big deal. It's certainly more convenient to eschew type safety. I'm > willing to let these bitrot back if t...

I think the implicit iterator conversions are much less important now that we have range based for loops, but I still like having them. On Tue, Oct 20, 2015 at 11:13 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Oct-07, at 17:57, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > > I've been

...efined size is translated into 8, 16, or 32 bit values in my buffer Although I do not know in detail about the actual implementation of libvorbis, most of the decoders should internally produce single-precision (32bit) floating point values, or 32bit integers as the result of PCM decoding. They are downcast to PCM samples with 8bit, 16bit, or whatever precision you designate. (So it is easily predicted that there is no point in extracting PCM audio with incongruously high precision from a stream with lower bitrates.) > does the pcm total only account for one channel? How are channels represented i...

...ullable type via an if-test. So for example > if x is nullable, and I test x != NULL, then inside the conditional > block the type of x is no longer nullable. Nullable types behave > slightly differently (and produce less efficient code) than non- > nullable types. For example, a downcast to a nullable type is a > dynamic cast (because if the cast fails, the result can be NULL), > whereas a downcast to a non-nullable type throws an exception if the > cast fails. > > This kind of analysis is trivial given LLVM's architecture. The > problem I have, howeve...

Hi all, Usually if we want to get the called Function we can directly use CallInst->getCalledFunction(), however, today i encounter an unusual CallInst as follows: %call11 = call double (...)* bitcast (double ()* @quantum_frand to double (...)*)() the original C source involve type cast: float u,v; extern double quantum_frand(); u = 2 * quantum_frand() - 1; v = 2 * quantum_frand() -

...est x != NULL, then inside the conditional block >> the >> type of x is no longer nullable. >> > > Makes sense. > > >> Nullable types behave slightly >> differently (and produce less efficient code) than non-nullable types. >> For example, a downcast to a nullable type is a dynamic cast >> (because if >> the cast fails, the result can be NULL), whereas a downcast to a >> non-nullable type throws an exception if the cast fails. >> > > Sure. > > >> This kind of analysis is trivial given LLVM'...

For a datapoint, Julia uses the following function description to implement approximately the capability of those functions. We then also verify that there's no direct inttoptr/ptrtoint into our gc-tracked AddressSpace with a custom verifier pass (among other sanity checks). I can provide additional details and pointers to our gc-root tracking algorithm implementation if desired (I also plan

v3->v4: - Fix x86-32 build error. v2->v3: - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted() in assembly as suggested by PeterZ. - Add a new patch to change vcpu_is_preempted() argument type to long to ease the writing of the assembly code. v1->v2: - Rerun the fio test on a different system on both bare-metal and a KVM guest. Both sockets were

v3->v4: - Fix x86-32 build error. v2->v3: - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted() in assembly as suggested by PeterZ. - Add a new patch to change vcpu_is_preempted() argument type to long to ease the writing of the assembly code. v1->v2: - Rerun the fio test on a different system on both bare-metal and a KVM guest. Both sockets were

The cpu argument in the function prototype of vcpu_is_preempted() is changed from int to long. That makes it easier to provide a better optimized assembly version of that function. For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the downcast from long to int is not a problem as vCPU number won't exceed 32 bits. Signed-off-by: Waiman Long <longman at redhat.com> --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/qspinlock.h | 2 +- arch/x86/kernel/kvm.c | 2 +- arch/x86/kernel/paravirt-s...

...>> The cpu argument in the function prototype of vcpu_is_preempted() >> is changed from int to long. That makes it easier to provide a better >> optimized assembly version of that function. >> >> For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the >> downcast from long to int is not a problem as vCPU number won't exceed >> 32 bits. >> > Note that because of the cast in PVOP_CALL_ARG1() this patch is > pointless. > > Then again, it doesn't seem to affect code generation, so why not. Takes > away the reliance on that wei...