search for: _znwm

...----------- next part -------------- 6646528 __memmove_sse2_unaligned __memmove_sse2_unaligned_erms 6630292 _ZN3lld3elf15scanRelocationsIN4llvm6object7ELFTypeILNS2_7support10endiannessE1ELb1EEEEEvRNS0_16InputSectionBaseE _ZNK3lld3elf10SymbolBody13isPreemptibleEv 6428622 __malloc _int_malloc 6415027 _Znwm __malloc 6296115 _ZSt17__merge_sort_loopIPN4llvm6object12Elf_Rel_ImplINS1_7ELFTypeILNS0_7support10endiannessE1ELb1EEELb1EEES8_lN9__gnu_cxx5__ops15_Iter_comp_iterIPFbRKS7_SD_EEEEvT_SH_T0_T1_T2_ _ZL15compRelocationsIN4llvm6object7ELFTypeILNS0_7support10endiannessE1ELb1EEENS1_12Elf_Rel_ImplIS5_Lb1EEEE...

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with

On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: > >> Hi, >> >> LLVM classifies _Znwm as a builtin by default. After some discussion, the >> C++ core working group have decreed that that is not correct: calls to >> "operator new" *can* be optimized, but only if they come from >> new-expressions, and not if they come from explicit calls to ::operator >&...

...lt;richard at metafoo.co.uk>wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >> >>> Hi, >>> >>> LLVM classifies _Znwm as a builtin by default. After some discussion, >>> the C++ core working group have decreed that that is not correct: calls to >>> "operator new" *can* be optimized, but only if they come from >>> new-expressions, and not if they come from explicit calls to ::op...

Hi, LLVM classifies _Znwm as a builtin by default. After some discussion, the C++ core working group have decreed that that is not correct: calls to "operator new" *can* be optimized, but only if they come from new-expressions, and not if they come from explicit calls to ::operator new. We cannot work around this...

On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: > Hi, > > LLVM classifies _Znwm as a builtin by default. After some discussion, the > C++ core working group have decreed that that is not correct: calls to > "operator new" *can* be optimized, but only if they come from > new-expressions, and not if they come from explicit calls to ::operator > new. We cann...

...ay 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Hi, > > LLVM classifies _Znwm as a builtin by default. After some discussion, the C++ core working group have decreed that that is not correct: calls to "operator new" *can* be optimized, but only if they come from new-expressions, and not if they come from explicit calls to ::operator new. We cannot work around this...

...rote: > >> On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >>> >>>> Hi, >>>> >>>> LLVM classifies _Znwm as a builtin by default. After some discussion, >>>> the C++ core working group have decreed that that is not correct: calls to >>>> "operator new" *can* be optimized, but only if they come from >>>> new-expressions, and not if they come from explicit c...

...lt;richard at metafoo.co.uk>wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >> >>> Hi, >>> >>> LLVM classifies _Znwm as a builtin by default. After some discussion, >>> the C++ core working group have decreed that that is not correct: calls to >>> "operator new" *can* be optimized, but only if they come from >>> new-expressions, and not if they come from explicit calls to ::op...

...tion (see recent patch on llvmcommits) >> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >> >> How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other option we could pursue? >> >> Wow, this was spectacularly unclear, sorry about that. To avoid confusion, I'm suggesting that we add a 'builtin' attribute, and do not treat a call to _Znwm as a builtin call unless it has...

...lock the optimization if the call happens through a >>>>> function pointer, unless we also annotate all calls through function >>>>> pointers as 'nobuiltin' >>>>> >>>>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be >>>>> opt-in rather than opt-out? Is there some other option we could pursue? >>>>> >>>> >> Wow, this was spectacularly unclear, sorry about that. To avoid >> confusion, I'm suggesting that we add a 'builtin' attribute, and do...

...cent patch on llvmcommits) >>> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >>> >>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other option we could pursue? >>> >>> Wow, this was spectacularly unclear, sorry about that. To avoid confusion, I'm suggesting that we add a 'builtin' attribute, and do not treat a call to _Znwm as a builtin call unles...

....com> wrote: > It's not clear to me that "builtin" is the right way to model this, but it > definitely sounds like this should be an attribute on a call site (as > opposed to on the function itself). What specific kinds of optimizations > are we interested in doing to _Znwm calls? You can see the paper to the C++ committee, but my primary goals. 1) run SROA over heap memory 2) pool together heap allocations on the same CFG trace 3) promote (sufficiently small and lifetime bounded) heap allocations to stack allocations -------------- next part -------------- An HTML...

...cent patch on llvmcommits) >>> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >>> >>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other option we could pursue? >>> >>> Wow, this was spectacularly unclear, sorry about that. To avoid confusion, I'm suggesting that we add a 'builtin' attribute, and do not treat a call to _Znwm as a builtin call unles...

...cate the following functions. I know that these are standard c++ library functions but g++ cannot locate them. Now my question is that where are these functions defined and how can I link them with my object files, and actually what do they do? declare noalias i8* @_Znam(i64) declare noalias i8* @_Znwm(i64) the emitted error messages are as follows: undefined reference to `operator new[](unsigned long)' undefined reference to `operator new(unsigned long)' We are reaching the deadline of the project but I haven't found any solution for this problem. So, please help me. Any help wou...

...ation if the call happens through a >>>>>> function pointer, unless we also annotate all calls through function >>>>>> pointers as 'nobuiltin' >>>>>> >>>>>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be >>>>>> opt-in rather than opt-out? Is there some other option we could pursue? >>>>>> >>>>> >>> Wow, this was spectacularly unclear, sorry about that. To avoid >>> confusion, I'm suggesting that we add a 'builtin...

...ow that these are standard c++ > library functions but g++ cannot locate them. Now my question is that where are > these functions defined and how can I link them with my object files, and > actually what do they do? > > |declare noalias i8* @_Znam(i64) > > declare noalias i8* @_Znwm(i64) > > the emitted error messages are as follows: > > undefined reference to `operator new[](unsigned long)' > > undefined reference to `operator new(unsigned long)' > > We are reaching the deadline of the project but I haven't found any solution for this probl...

Hi! When I allocate memory for a structure, in _Znwm (operator new) function I need to specify size. How can I determine this information dynamically? ; ModuleID = '/tmp/webcompile/_12211_0.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:12...

On May 16, 2013, at 12:36 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > > Since it would probably help to quantify the complexity increase, I've implemented my more recent suggestion (patch attached). This patch allows 'nobuiltin' on a function declaration or definition, and adds a 'builtin' attribute which can only be present on a call site for a

On Thu, May 16, 2013 at 10:13 AM, Chris Lattner <clattner at apple.com> wrote: > On May 15, 2013, at 10:32 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > Initially, I'm just concerned about keeping the optimizations we already >>> perform, such as globalopt lowering a new/delete pair into a global, while >>> disabling the non-conforming