search for: devirtualised

On Mon, Dec 3, 2012 at 9:21 AM, David Tweed <david.tweed at arm.com> wrote: > -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of David Blaikie > Sent: 03 December 2012 16:41 > To: Renato Golin > Cc: LLVM Developers Mailing List; cfe-dev > Subject: Re: [cfe-dev] [LLVMdev] RFC: Change tests to run with

Hi, > For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* > %1604) > > How can I resolve the targets of these? Also, why are they appearing as > indirect calls in the IR, when they are direct calls in the source? You don't mention what language you're trying to compile, though it looks plausibly C++. I'd guess these are virtual function calls.

I am coming up against a lot of function pointers in the IR, although the corresponding source code does not have indirect calls. For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* %1604) How can I resolve the targets of these? Also, why are they appearing as indirect calls in the IR, when they are direct calls in the source? Thanks. -Apala

Hi all, We consistently see test failures arising because by default many of our tests run in a mode where the tool (clang or llc) pick host-dependent behavior. This makes it easy for developers to write tests that pass on their system, but fail for other developers. There is some utility in this behavior, as it gives us (unintended) testing coverage of some things, but overall I think it is a

My thoughts: On Sat, Dec 1, 2012 at 9:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com>wrote: > >> I'm ok with this in principle, but how about with the nuance that some >> tests (eg test/codegen) explicitly opt into march=native? >> > > I'd really like the default

On 3 December 2012 17:21, David Tweed <david.tweed at arm.com> wrote: > Just a point here: the reason I'd mildly prefer not to have a default that > avoids as much target dependent stuff as possible is that it's generally > going to have a higher probability of passing even if something is "wrong" > in the sense that, eg, if the return type of some thing is ABI

On Tue, Jan 23, 2018 at 12:55:31AM +0800, 张少华 wrote: > We realise our score function using PostingSource instead of using > KeyMaker, we reference your python example and source code of xapian, > the simple demo is here. > https://github.com/xiangqianzsh/xapian_leaning/blob/master/postingsource/ExternalWeightPostingSource.h I'd just put the get_weight() and get_maxweight()

Hi Tim, This is C++ indeed. Basically, I am profiling the code. So, these edges that cannot be resolved at compile time present a problem. Where can I find these devirtualization optimizations that you mentioned? Thanks. -Apala On 01/01/2013 12:18 PM, Tim Northover wrote: > > Hi, > > > For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* > > %1604)

> On Aug 7, 2015, at 12:32 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Aug 7, 2015 at 11:30 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > I’ve almost finished a patch to add back in either out of line destructors or anchor methods. We seem to use one or the one, relatively inconsistently. >

>A possible workaround (and perhaps a better approach) would be to >set BoolWeight as the weighting scheme, then feed in your score as >a weight using a PostingSource. Then it's available via get_weight() >on the MSetIterator object: > >https://getting-started-with-xapian.readthedocs.io/en/latest/advanced/postingsource.html > >You may find that's faster because

The proposed addition to ProgrammersManuel.rst is below the break... This is essentially trying to explain the emerging design techniques being used in LLVM these days somewhere more accessible than the comments on a particular piece of infrastructure. It covers the "concepts-based polymorphism" that caused some confusion during initial reviews of the new pass manager as well as the

I'm ok with this in principle, but how about with the nuance that some tests (eg test/codegen) explicitly opt into march=native? -Chris On Nov 30, 2012, at 12:16 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi all, > > We consistently see test failures arising because by default many of our tests run in a mode where the tool (clang or llc) pick host-dependent behavior.

On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: > I'm ok with this in principle, but how about with the nuance that some > tests (eg test/codegen) explicitly opt into march=native? > I'd really like the default behavior to be something that forces the test to either be independent of the targeted triple, or explicitly set a target. I like the

On Mon, Dec 3, 2012 at 1:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > Apart from what has already being said, which I agree mostly, I have > some specific comments: > > >> a. We change the test suite to run in such a way that all tools default to >> an "unknown" host triple. > > The assumptions will be different and I believe the

I’ve almost finished a patch to add back in either out of line destructors or anchor methods. We seem to use one or the one, relatively inconsistently. What i’ve gone for is that if a class already had an inline destructor then i left it alone and added an anchor method. Otherwise I added an out of line destructor. Now if I compile Instructions.cpp with -Wweak-vtable, the only warnings given