search for: setdoesnotaccessmemori

Hello, I'm in a situation where my code is calling many native functions. Sometimes, these calls are simply calls to static "accessor" methods that read a variable in some class object (object pointer as input, member variable value returned as output). I was wondering if using the setOnlyReadsMemory method on the native function objects could help LLVM generate optimized code

But, which optimization pass will take advantage of those flags? As for nounwind, that means "can't throw an exception"? - Maxime John McCall-2 wrote: > > Nyx wrote: >> Hello, >> >> I'm in a situation where my code is calling many native functions. >> Sometimes, these calls are simply calls to static "accessor" methods that >>

Nyx wrote: > Hello, > > I'm in a situation where my code is calling many native functions. > Sometimes, these calls are simply calls to static "accessor" methods that > read a variable in some class object (object pointer as input, member > variable value returned as output). I was wondering if using the > setOnlyReadsMemory method on the native function objects

Hi Mehdi, The ISO C specification does permit the math functions to modify ‘errno’, but I thought that the ‘-fno-math-errno’ option was to tell the optimiser to assume that ‘errno’ is not modified by the math functions. Explicitly providing ‘-fno-math-errno’ is not restoring the elision optimisation that was performed by LLVM v3.8, and this is really only a driver option, with ‘-fmath-errno’

A little while ago I asked a question on CFE-Dev about a change in the behaviour of programs using the ISO C math functions, although that question should have been put to LLVM-Dev. But I got excellent clarification of the problem anyway. However, since then I have been trying to adapt our out-of-tree implementation to get the previous behaviour. The problem is that something like: #include

On Wednesday 01 April 2009 20:01:09 Dan Gohman wrote: > On Apr 1, 2009, at 7:25 AM, Torvald Riegel wrote: > > On Wednesday 25 March 2009, Luke Dalessandro wrote: > >> You could encode this information as simple library function calls > >> and > >> then find them again in the generated LLVM IR. The client then just > >> needs a header declaring the

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >