search for: devirtualisation

...t you have in mind? > if you happen to be doing this > on an ABI where the where the value differs depending where it is obtained > from then you'll probably catch errors that are "latent errors" for the > simpler ABI. (Yes, this is a thinly disguised version of the > devirtualisation issue, but I do think this phenomenon may apply elsewhere: > the less complicated an ABI the more chance that something "slightly wrong" > will actually pass.) Those are my thoughts anyway. > > Regards, > Dave > > >

...s plausibly C++. I'd guess these are virtual function calls. In general you can't tell which actual function will be called at compile-time, since it will depend on the precise class of the object being used. LLVM can unpick some of this (the optimistions go under the generic term of "devirtualisation"), but obviously not all. If you as a reader just want to know what function's being called in broad terms, I'd look at where that %1608 comes from: likely loaded from an offset in the vtable, stored in %1604. Very roughly for Unixy ABIs (and loosely typed): %vtable = load i8** %1604...

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

...tions without doing that); again the upshot has been to have these requirements specified explicitly. There have been 5-10 JIT code tests where "support" code pasted from, eg, lli into a test hadn't been updated when the JIT core was changed. The one definite bug that was there was in devirtualisation (which probably lowered ok but failed the module verifier). This bug was definitely not visible due to the general set of ARM failures that were basically issues with the tests. So on the one hand, I'd love it if the tests were constructed in such a way that the "fuzz" of ABI differe...

...aces give the same result; if you happen to be doing this > on an ABI where the where the value differs depending where it is obtained > from then you'll probably catch errors that are "latent errors" for the > simpler ABI. (Yes, this is a thinly disguised version of the > devirtualisation issue, but I do think this phenomenon may apply elsewhere: > the less complicated an ABI the more chance that something "slightly wrong" > will actually pass.) Those are my thoughts anyway. I suppose I had that feeling, but couldn't put my finger on it, and to be honest, I stil...

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()

...ese are virtual function calls. In > general you can't tell which actual function will be called at > compile-time, since it will depend on the precise class of the object > being used. > > LLVM can unpick some of this (the optimistions go under the generic > term of "devirtualisation"), but obviously not all. > > If you as a reader just want to know what function's being called in > broad terms, I'd look at where that %1608 comes from: likely loaded > from an offset in the vtable, stored in %1604. Very roughly for Unixy > ABIs (and loosely typed):...

...didn’t really like the look of what I did either which is why i thought it best to explain it. I’m happy to change over what I’ve done to anchor’s, but its unfortunate that it will then differ from some of the other sibling classes. Perhaps this is moot* though, if I can get back to finishing the devirtualisation without any perf issues. * moot for ToT perhaps. I’m happy to get something for 3.7 if we can work out what it should be. The options seem to be - Do nothing to the code, except perhaps change llvm-config as David said - This patch - The equivalent to this with anchor’s. Anyone got a strong opi...

>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