search for: machineri

Anyone have opinions on whether the cast machinery should be taught to handle unique_ptr? Presumably that'd involve cast, etc, returning raw pointers when it was passed references to unique_ptr, which might be surprising/error-prone? But the only errors would be: 1) double delete - if the result of the cast was used to take ownership because the caller didn't realize there was a

On 26/07/12 14:59, Rafael Espíndola wrote: > On 26 July 2012 08:45, George Baah <georgebaah at gmail.com> wrote: >> Hi Folks, >> Is a java frontend still being developed for llvm? > > Closest thing I know is gcj + dragonegg, but it is a lot of work to be > done in gcj before it works with dragonegg. the main issue I know about is that gcj wants to output

On Fri, Oct 11, 2013 at 12:07 PM, Eric Christopher <echristo at gmail.com>wrote: > > > > Since we don't have ODR, we may have macros defined differently for a > struct > > in a .h file, > > thus having two versions of the struct from two different CU. It seems > that > > we can't assume > > structs with the same name and defined in the same

On Jul 17, 2013, at 2:12 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote: >>> ** Advices

On Fri, Oct 11, 2013 at 12:40 PM, Eric Christopher <echristo at gmail.com>wrote: > >> It depends upon the goals. If the goal is to make debug information > >> post-link smaller then just using the type hashing machinery for > >> structs will be sufficient. > > > > > > By "the type hashing machinery for structs", are you referring to the

On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > > ** Advices Needed ** > > 1. Decide whether or not we want such capabilities (if we do not we may >

Sent from my iPad On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 17, 2013, at 2:12 AM, Chandler Carruth <chandlerc at google.com> wrote: > >> On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: >>> >>> On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com>

On 9/29/11 11:23 AM, Eric Christopher wrote: > On Sep 29, 2011, at 12:53 AM, Speziale Ettore wrote: > >> Hi, >> >>> What compiler are you using to build with? I've made it default to clang with less looking around for llvm-gcc, so there may be an issue there. What is your configure line? What host are you trying to build on? >> First I have compiled llvm/clang

On Dec 18, 2008, at 7:05 PM, Sandeep Patel wrote: > Since there have been no answers, I will have to start at the > beginning. > > One of the first changes I'd like to try is adding the additional > registers and the AAPCS VFP variant calling conventions. Is there a > reason why the ARM Target isn't using the CCState machinery? Please clarify. I am not sure what you

>> It depends upon the goals. If the goal is to make debug information >> post-link smaller then just using the type hashing machinery for >> structs will be sufficient. > > > By "the type hashing machinery for structs", are you referring to the type > hashing at the back end? > I am, yes, since there's no other place we do currently. >>

Chandler, Thank you for getting it up to ML top. I believe we have to move broader than that you just mentioned. The natural separation of the infrastructure into different parts can be across the following lines: - the parallel model of programming - these can be OpenMP, OpenACC, CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc. - the offloading machinery to be used by any

On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote: >> ** Advices Needed ** >> >> 1. Decide whether or not we want such capabilities (if we do not we may just >> add sporadically the support for a new warning/group of warning/error). >> 2. Come

So for mergeable bufs, we use ewma machinery to guess the correct buffer size. If we don't guess correctly, XDP has to do aggressive copies. Problem is, xdp paths do not update the ewma at all, except sometimes with XDP_PASS. So whatever we happen to have before we attach XDP, will mostly stay around. The fix is probably to update ewma unconditionally. -- MST

So for mergeable bufs, we use ewma machinery to guess the correct buffer size. If we don't guess correctly, XDP has to do aggressive copies. Problem is, xdp paths do not update the ewma at all, except sometimes with XDP_PASS. So whatever we happen to have before we attach XDP, will mostly stay around. The fix is probably to update ewma unconditionally. -- MST

On 9/29/11 11:45 AM, Eric Christopher wrote: >> (I'm jumping into the middle of this conversation as it looks like you're discussing something that might be relevant to my work. Sorry I'm not up to speed on the full context of the discussion...) >> >> If you are asking whether anyone is using machinery in LLVM's build system to compile programs into LLVM bitcode

>> > > (I'm jumping into the middle of this conversation as it looks like you're discussing something that might be relevant to my work. Sorry I'm not up to speed on the full context of the discussion...) > > If you are asking whether anyone is using machinery in LLVM's build system to compile programs into LLVM bitcode files, the answer is yes. The LLVM

Been having a bit of a problem with dyn_cast: Suppose I have a class A that inherits from two base classes, both of which support dyn_cast. In order to use dyn_cast on A, I need to do a bunch of extra work: 1) Since dyn_cast uses reinterpret_cast rather than static_cast, the pointer value won't get adjusted by the cast operation, making the pointer invalid. I end up having to redefine

On 01/05/2017 03:10 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > I don't understand why that's desirable, and I think it would > severely limit our ability to infer these attributes for functions > that unwind. You'd need to prove things -- likely

On Mon, Oct 14, 2013 at 1:08 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Fri, Oct 11, 2013 at 12:40 PM, Eric Christopher <echristo at gmail.com>wrote: > >> >> It depends upon the goals. If the goal is to make debug information >> >> post-link smaller then just using the type hashing machinery for >> >> structs will be

Hi, Thanks all for the insight comments. Let me sum up at a high level what proposals we actually have (sorry if I misinterpreted or missed something, do not hesitate to correct me): 1. Make LLVM defines some APIs that exposes some internal information so that a front-end can use them to build-up some diagnostics. 2. Make LLVM builds up a diagnostic and let a front-end maps this diagnostic to