search for: downcasts

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 scrubbed... URL:

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 "numbers" in LLVM IR is neither signed

...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)....

In the language I am working on, there are cases where the call flow graph can affect the type of a variable. A simple example is a "nullable" type (a pointer which is allowed to be NULL), which can be 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.

On Wed, Feb 15, 2017 at 04:37:49PM -0500, 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

On Wed, Feb 15, 2017 at 04:37:49PM -0500, 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

On May 23, 2008, at 11:53 PM, Talin wrote: > In the language I am working on, there are cases where the call flow > graph can affect the type of a variable. Ok. > A simple example is a > "nullable" type (a pointer which is allowed to be NULL), which can be > converted into a non-nullable type via an if-test. So for example if x > is nullable, and I test x != NULL,

Does llvm have a pass that minimizes the bitwidth of llvm instructions? For instance:   %8 = and i32 %7, 63 63 is 111111 in binary. So the 'and' instruction only requires 6 bits. We could rewrite the above code as:   %8 = trunc i32 %7 to i6   %9 = and i6 %8, 63 Since we only need the lower 6 bits we could also propagate this change backwards to reduce the bitwidth of prior

...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>

...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 that's better. > > Now that I've rooted out the bugs I was looking for (confirmed LLVM > is clean as of r250852) I&...

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

Hello Martin, > how a number of samples with no defined 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

On May 24, 2008, at 02:53, Talin wrote: > In the language I am working on, there are cases where the call flow > graph can affect the type of a variable. A simple example is a > "nullable" type (a pointer which is allowed to be NULL), which can > be converted into a non-nullable type via an if-test. So for example > if x is nullable, and I test x != NULL, then

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() -

Thanks (everyone) for the suggestions, they were helpful. What I decided to do was to essentially "wrap" LLVM's BasicBlock structure with my own block class that contains additional high-level information. Up to this point I was generating LLVM basic blocks on the fly as I walked the statement tree; Now I build my own BB graph, and then use that to generate the BB graph for

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> ---

On 02/16/2017 11:09 AM, Peter Zijlstra wrote: > On Wed, Feb 15, 2017 at 04:37:49PM -0500, 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),