search for: reinterpreting

...return str.c_str(); }* when I call this from R: *str <- test() typeof(str) % result is: "externalptr"* how could I reinterpret this to a charcterarray, to a numeric, to list, or ... Thanks for any suggestions ;) -- View this message in context: http://r.789695.n4.nabble.com/reinterpreting-externalptr-in-R-tp4653908.html Sent from the R devel mailing list archive at Nabble.com.

On Sep 22, 2011, at 3:32 AM, James Molloy wrote: > It’s in trouble by this point because it needs to do a fptosi on a double operand, but you’ve got an i64 operand and you can’t reinterpret-cast ints to floats in LLVM IR (AFAIK) You can bitcast ints to floats and vice-versa if they're the same size — for example, i32 to float and i64 to double. John.

Hello, I am writing an R/Go interoperability tool[1] that work similarly to Rcpp; the tool takes packages written in Go and performs the necessary Go type analysis to wrap the Go code with C and R shims that allow the Go code to then be called from R. The system is largely complete (with the exception of having a clean approach to handling generalised attributes in the easy case[2] - the less

Hi Sanjiv, The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic that reinterprets the "section" field of a global in a strange way: // If GV has a sectin name or section address create that section now. if (GV->hasSection()) { std::string SectName = GV->getSection(); // If address for a variable is specified, get the address and create

...t; change what instructions are used based on target platform and its > endedness. One reason for writing code like this, i.e. explicitly spelling out the accesses to the individual bytes, would be to allow compile-time evaluation of the fragment in the D programming language, where arbitrarily reinterpreting memory is not supported (although integer->integer pointer casts might be supported at some point). Would a patch adding the capability to lower this to InstCombine or similar have a chance of being accepted, or would that be considered to be too rare a spacial case to be worth the added comple...

My general feeling is this: No optimizations should be creating int2ptr/ptr2int. We really need to fix them all. They should use pointer casts and i8* GEPs. This has, unfortunately, been a problem for a long time. As Johannes says, optimizing int2ptr/ptr2int is very tricky. In part, becaue all dependencies, including implicit control dependencies, end up being part of the resulting aliasing

Hi, We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) Is there any code available in LLVM to handle this kind of "standard float to LLVM float" conversion? Thanks. Stéphane Letz

On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: > Hi, > > We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) > > Is there any code available in LLVM  to handle this kind of

On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote: > On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote: [...] > > Have you read Documentation/process/code-of-conduct- > > interpretation.rst? > > As has been pointed out, it contains a clear answer to how things > > should be interpreted here. > > Ugh, was not aware that there two documents.

I think we need to relax the test cases. MSVC usually prints the calling convention, and it's often useful information. Maybe we can make the diagnostic text smaller by using the __thiscall, __cdecl, __stdcall, etc keywords when printing types with LangOpts.MicrosoftExt, but it will require moving the attribute from after the identifier to before, which is exciting. On Tue, Dec 10, 2013 at

...= fptosi double %1 to i64 ; Perform explicit double -> int conversion. %4 = fptosi double %2 to i64 %5 = shr i64 %3, %4 ; Perform your operation. %6 = sitofp i64 %5 to double ; Convert explicitly back to integer representation. %7 = store bitcast i8* %dest to double*, double %6 ; Store back, reinterpreting your void* (which is i8* in LLVM) as a double*. Hopefully this makes sense, especially if you know how you would have to do it in C. Cheers, James From: sarath chandra [mailto:sarathcse19 at gmail.com<mailto:sarathcse19 at gmail.com>] Sent: 22 September 2011 10:49 To: James Molloy Subjec...

Good to know, thanks. The docs are slightly hazy on that - they do mention type-to-type if same size, but the examples are only between pointers and integers, not floats. Would it be worthwhile my updating the documentation to explicitly state that or is it just me? Cheers, James -----Original Message----- From: John McCall [mailto:rjmccall at apple.com] Sent: 23 September 2011 00:06 To: James

...;> %4 = fptosi double %2 to i64 >> >> %5 = shr i64 %3, %4 ; Perform your operation. >> >> %6 = sitofp i64 %5 to double ; Convert explicitly back to integer >> representation. >> >> %7 = store bitcast i8* %dest to double*, double %6 ; Store back, >> reinterpreting your void* (which is i8* in LLVM) as a double*. >> >> >> Hopefully this makes sense, especially if you know how you would have to >> do it in C. >> >> Cheers, >> >> James >> >> From: sarath chandra [mailto:sarathcse19 at gmail.com] >&gt...

On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> It would be nice if we could make the TypePrinter not print the >> calling convention if it's the default one for the ABI, but >> TypePrinter doesn't have a lot of context.. no Sema, no

Hi James, > The docs are slightly hazy on that - they do mention type-to-type if same size, but the examples are only between pointers and integers, not floats. you can't use bitcast to convert a pointer to an integer or vice-versa. You must use ptrtoint/inttoptr. Ciao, Duncan. Would it be worthwhile my updating the documentation to explicitly state that or is it just me? > >

Substituting the uses of a global with an absolute address would make all accesses to that global through pointer, which is very inefficient on PIC16. So we don't change the code generation for that global; instead we only pass the address information to the linker (home made linker) through some assembly directives. What are you trying to do? Are you trying to change the logic of this part or

...e used based on target platform and its > > endedness. > > One reason for writing code like this, i.e. explicitly spelling out > the accesses to the individual bytes, would be to allow compile-time > evaluation of the fragment in the D programming language, where > arbitrarily reinterpreting memory is not supported (although > integer->integer pointer casts might be supported at some point). > > Would a patch adding the capability to lower this to InstCombine or > similar have a chance of being accepted, or would that be considered > to be too rare a spacial case to...

On 08/08/2013 02:16 PM, Justin Holewinski wrote: > Why should SelectionDAGBuilder generate an explicit bitcast for a no-op > bitcast? The bitcast operation isn't just the reinterpretation (change in the semantic) of the bits without any change in the value of the bits itself? If the size and value do not change should be fine. > By definition, no bits are changed; so if the EVTs

On Tue, 14 Aug 2018 at 11:56, Kim Gräsman <kim.grasman at gmail.com> wrote: > > On Tue, Aug 14, 2018 at 11:51 AM Andrew Haley <aph at redhat.com> wrote: > > > > On 08/12/2018 02:19 PM, Kim Gräsman wrote: > > > I still feel a little uncomfortable, because I think Jonathan makes an > > > excellent point -- if GCC thinks there's a strict-aliasing

2012/9/13 Kaylor, Andrew <andrew.kaylor at intel.com>: > I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32?