search for: reinterpretation

Hi, I am using swig to build a wrapper for an c-function to use it in R. I would like to define a generic function, which gives back a void pointer. On the R side, I know what this pointer is pointing to, whether it is an integer or an string, or something else... but I need to somehow reinterpret the resulting "externalptr" into another form... a function that looks like the

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.

...;s interface assertions in a number of cases I have decided to reinterpret R_NilValue to an untyped Go nil (this is important for example in list traversal where the CDR can (hopefully) be only one of two types LISTSXP or NILSXP; in Go this would require a generalised SEXP return, but by doing this reinterpretation I can return a *List pointer which may be nil, greatly simplifying the code and improving the performance). My question her is why a singleton null value was chosen to be represented as a fully allocated SEXP value rather than just a C NULL. Also, whether C NULL is used to any great extent within t...

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

On Mon, Oct 28, 2013 at 10:09 AM, James Courtier-Dutton <james.dutton at gmail.com> wrote: > My guess is that this is a missed optimization, but in real life, all > projects i have worked fix this in the C or C++ code using macros that > change what instructions are used based on target platform and its > endedness. One reason for writing code like this, i.e. explicitly spelling

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

Hi Sarath, It would have really helped if you had removed the commented out code and inlined the calls to your homemade helper functions before sending it... You are doing this, in LLVM IR: %0 = getelementptr %Value* %firstArg, i32 0 ; i8** %1 = load i8** %0 ; i8* %2 = bitcast i8* %1 to i64* %3 = getelementptr %Value* %secondArg, i32 0 ; i8** %4 = load i8** %3; i8* %5 = bitcast i8* %4 to i64*

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

On Thu, Sep 22, 2011 at 3:46 PM, sarath chandra <sarathcse19 at gmail.com>wrote: > Hi James, > > First i converted the void * to int* and then did FPToSI...then did SHL...( > because CreateShl only accepts integers... i pointer casted it to int64 type > first)... Below is the code snippet.... > > > lhs = mBuilder.CreateStructGEP(firstArg, 0); > lhs =

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

----- Original Message ----- > On Mon, Oct 28, 2013 at 10:09 AM, James Courtier-Dutton > <james.dutton at gmail.com> wrote: > > My guess is that this is a missed optimization, but in real life, > > all > > projects i have worked fix this in the C or C++ code using macros > > that > > change what instructions are used based on target platform and its >

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 match, > there is nothing to do. The fundamental problem is how address spaces > are handled...

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?