similar to: [LLVMdev] expression statements, volatiles, and C vs. C++

LLVM doesn't know about any of this C/C++ specific stuff. If g++ do something (such as the load), so will llvm-g++. I'd suggest you send this to the clang mailing list. BTW, this issue is very interesting. I've never used C++ for embedded systems so never realised this difference. On Sat, Mar 6, 2010 at 1:47 AM, John Regehr <regehr at cs.utah.edu> wrote: > The question is,

Hi All, I'm writing a code generation with my compiler. I read sever example and documentation but I did understand what I make wrong. What I try to do is a compare a local variable with a constant. But when I create a ICMP instruction I get that instruction are not of same type. I'm using llvm by svn repository updated at two week ago. The code that I try to generation is something

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg

you're not showing enough code. What does accept() do? Based on your description, I strongly suspect that your alloca and constant are not the same type. Remember that alloca returns a pointer type that you must load to get at the actual variable. On Jan 11, 2013 3:28 AM, "Manuele Conti" <manuele.conti at sirius-es.it> wrote: > Hi All, > I'm writing a code

Hi Justin, my class is a visitor pattern and I use accept method to go recursive in suboject in my AST. In locals I store AllocaInst pointer. void *visit(var1_init_decl_c *symbol) { llvm::Type *lType; varNames.clear(); varType = ""; symbol->var1_list->accept(*this); /* get a vector contains variable names */ symbol->spec_init->accept(*this); /* Store in

On Fri, Jan 11, 2013 at 8:20 AM, Manuele Conti <manuele.conti at sirius-es.it>wrote: > Hi Justin, > my class is a visitor pattern and I use accept method to go recursive in > suboject in my AST. > In locals I store AllocaInst pointer. > > > void *visit(var1_init_decl_c *symbol) { > llvm::Type *lType; > > varNames.clear(); > varType = "";

On May 11, 2010, at 8:40 PM, Andrew Sutton wrote: > > What's driving libc++? > > The possibility of being a superior solution. > > I thought "to support Apple applications" from the previous post was sufficient motivation :) Either way, I'm excited about a new library. Plus, it looks a little easier to read (from the tiny amount of code that I've looked

On 11/24/2012 04:14 AM, john skaller wrote: > > On 24/11/2012, at 10:21 PM, Nick Lewycky wrote: > >> >> Passing an uninitialized value as a function argument is undefined behaviour on the spot, regardless of what the callee does (even if it never references that argument). > > Cite reference? No? Then you're guessing ;) This is a rule in C++ that I'm not sure

----- Original Message ----- > On 9/12/2013 7:44 PM, Hal Finkel wrote: > > > > To fix this problem, I think that we need to stop treating errno as > > some arbitrary external state, and model is explicitly. > > In such case it would make sense to know when "errno" is read. This > way > we could detect whether it's actually used, whether or not the

On 08/11/2011 02:56 PM, Duncan Sands wrote: > Hi Florian, > >> we'd like to be able to check for loss of information in trunc operations in >> our LLVM-based bounded model checker [1]. For this it is important if the >> trunc was on a signed or unsigned integer, so we need nsw and nuw flags for >> this. Would you accept a patch that adds these flags to LLVM (and

Hi, I didn't do any serious benchmarking but so far I never found a case where LLVM does better than IAR on CortexM0, but I saw a lot of cases where IAR output is better than LLVM... That said I did not use -Os or -Oz, I just used -O3. A recurrent situation is that LLVM push/pop one or two extra registers compared to IAR, I guess it does so in order to comply with a standard ABI or

What about benchmarks on other Arm devices? On 02/26/2013 02:52 PM, Jim Grosbach wrote: > Cortex-M0 is a Thumb1 only device. There hasn't been any concerted > effort to tune LLVM's Thumb1 output in quite a long time. Even back then > (2008 or so), the effort was mainly to get it to work acceptably, with > the real performance tuning work being done for Thumb2. I'm not >

Cortex-M0 is a Thumb1 only device. There hasn't been any concerted effort to tune LLVM's Thumb1 output in quite a long time. Even back then (2008 or so), the effort was mainly to get it to work acceptably, with the real performance tuning work being done for Thumb2. I'm not surprised that an embedded market focussed compiler like IAR is better tuned for a chip like that. -Jim On Feb

The attached file contains some simple functions that manipulate volatile varibles. The functions near the top of the file should turn into code that loads from x and then stores to it. The LLVM version on the web (not sure if it's the latest...) gets most of these wrong. John Regehr -------------- next part --------------

> How crazy would it be for us to start using basic C++'11 language features (but not C++'11 library features) in LLVM: > things like auto | It can make code less readable because of missing types. When compiler can deduce type, it doesn't always mean that human do it easily when reading the code. I'd argue that auto should only be used in cases where the precise type being

On 9/13/2013 2:23 PM, Hal Finkel wrote: > > Maybe the easiest way would be to insert an intrinsic @llvm.errno.read() whenever errno (as a source token) appears in the source as an rvalue (and do some similar thing when it appears as a lvalue). Thoughts? I think the major problem is still with "errno" defined as a preprocessor macro, as it may not look like errno by the time the

I've not run any on non-iOS devices, and haven't looked at GCC since v4.2.1 due to licensing issues, so I don't have a good feel for comparative benchmarking. -Jim On Feb 26, 2013, at 4:20 PM, Reed Kotler <rkotler at mips.com> wrote: > What about benchmarks on other Arm devices? > > On 02/26/2013 02:52 PM, Jim Grosbach wrote: >> Cortex-M0 is a Thumb1 only

> > This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway). Errr, that is a pretty old version at this point. Also this was before significant performance improvements were target at libstdc++ *and* g++. It seems a bit strange to compare something from today to something that is now 3 release versions old.

On Thu, Nov 7, 2013 at 11:02 AM, Yin Ma <yinma at codeaurora.org> wrote: > Hi John, > > > > It seems the dereferencing a NULL pointer is undefined behavior but > > Calling a function through a null pointer seems o.k. > What is the well defined behavior of calling a null function pointer? > > > If so , for this place, we need comment out the check. >

On Sep 11, 2007, at 3:49 PM, John Regehr wrote: > The attached file contains some simple functions that manipulate > volatile > varibles. The functions near the top of the file should turn into > code > that loads from x and then stores to it. The LLVM version on the > web (not > sure if it's the latest...) gets most of these wrong. Hi John, This appears to work