search for: impementation

On 8 Jun 2015, at 21:08, Eric Christopher <echristo at gmail.com> wrote: > > I'd rather not have it be an llvm option at all. Just construct a different set of passes... > > This would also solve the problem of needing multiple sets of options to be passed to the builder. It'd be a bit of a change (i.e. having clang do the pass setup), but I think it'd be worth it

On Thu, Jun 4, 2015 at 5:02 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015 Jun 4, at 16:51, Reid Kleckner <rnk at google.com> wrote: >> >> On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> > Personally, I think the right approach is to add a bool to createGlobalDCEPass defaulting to

> On 2015-May-15, at 13:15, Teresa Johnson <tejohnson at google.com> wrote: > > What isn't clear to me is what all uses the available > externally linkage type currently - do you happen to know? It's used for the `inline` keyword in the C language. If you do a `git grep available_externally -- test/` inside a clang checkout you might find some other uses. $ cat

On Thu, Jun 4, 2015 at 11:27 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > Since the compiler is always free to delete available_externally > functions, I think you could just add a pass to the -flto=thin pipeline > that deletes all of them (referenced or not) -- it's just a single loop > through all the functions deleting the bodies of those with the right

On Fri, May 15, 2015 at 5:11 AM, Dave Bozier <seifsta at gmail.com> wrote: > > Are you sure about the additional I/O? With native symtab, existing > tools just need to read those, while plugin based approach needs to read > bit code section to feedback symbols to the tool. > > The additional I/O will be quite big if you are going to emit the full > symbol table. Looking

On Fri, May 15, 2015 at 9:18 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> - Marking of imported functions (for use in ThinLTO-specific symbol >> >> linking and global DCE, for example). >> > >> > Marking how? Do you mean giving them internal linkage, or something >> > else? >> >> Mentioned just after this: either

...until I replaced the dotted quad > > > address with the DNS name. Thank you. I think a change in the > > > documentation is due. > > > > It's actually a bug in the core. > > This bug has an unpleasant consequence. > > The Oracle VirtualBox 4.2.16 PXE impementation does not request Option 6 > from the DHCP server, so it does not receive Option 6 in the DHCP > offer, so no DNS servers are available to pxelinux, therefore it > cannot resolve the WDS server's IP address, which breaks everything. > > Can we get rid of this dependency on DNS?...

On Jul 16, 2013 8:13 AM, "Victor Sudakov" <vas at mpeks.tomsk.su> wrote: > > Gene Cumm wrote: > > >> > > >> Did you try without "-o 66..."? Any chance for a packet capture from a > > >> mirrored port or the dhcpd+tftpd-old+tftpd-new+dnsd? > > > > > > OK, I have tried the following: > > > > > >

On Thu, Jun 4, 2015 at 9:51 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 07:10, Teresa Johnson <tejohnson at google.com> wrote: >> >> On Wed, Jun 3, 2015 at 2:07 PM, Duncan P. N. Exon Smith >> <dexonsmith at apple.com> wrote: >>> >>>> On 2015-Jun-03, at 09:56, Teresa Johnson <tejohnson at

On Mon, Jun 8, 2015 at 11:33 AM, Reid Kleckner <rnk at google.com> wrote: > The clang patch lgtm, and I had some comments on the LLVM patch. Duncan, do > you want to say more there? > > --- include/llvm/Transforms/IPO/PassManagerBuilder.h (revision 237590) > +++ include/llvm/Transforms/IPO/PassManagerBuilder.h (working copy) > @@ -121,6 +121,7 @@ class PassManagerBuilder {

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

On Fri, May 15, 2015 at 9:53 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 15, 2015 at 9:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > On Fri, May 15, 2015 at 9:18 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >>> > >>> > >>> >> - Marking of imported functions (for use

On Fri, May 15, 2015 at 12:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote: > > > >>> a. Lazy Debug Metadata Linking: > >>> > >>> The prototype implementation included lazy importing of module-level > >>> metadata during the

Hi everyone and thanks for being patient. I've used "!.foo"() et seq pro tem. Next problem: how to define "Summary" methods for brobs. ?max says 'max' and 'min' are generic functions: methods can be defined for them individually or via the 'Summary' group generic. For this to work properly, the arguments '...' should be

On Wed, Jun 3, 2015 at 2:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-03, at 09:56, Teresa Johnson <tejohnson at google.com> wrote: >> >> On Tue, May 19, 2015 at 1:18 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> >>> On Tue, May 19, 2015 at 1:05 PM, Teresa Johnson <tejohnson at

On Fri, May 15, 2015 at 11:20 PM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 15, 2015 at 2:52 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> On Fri, May 15, 2015 at 1:15 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >>> >>> On Fri, May 15, 2015 at 10:04 AM, David Blaikie <dblaikie at

> > >> I don't think that natively wrapped bitcode gets you as much as you think >> it does anyhow, unless you're duplicating a lot of information (ar, as >> discussed earlier, aside). I'm not too worried about the build system as >> far as a wrapping mechanism >> > > Do not under estimate the importance of build system integration. Tools >

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

On Tue, May 19, 2015 at 1:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, May 19, 2015 at 1:05 PM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> On Tue, May 19, 2015 at 12:41 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> > >> > >> > On Mon, May 18, 2015 at 9:09 PM, Teresa Johnson

Talked to Eric Fri and he suggested that this might be the first of several places where we want behavior of LTO compiles to diverge from normal -O2 compiles. So for now I have implemented this such that we pass down -flto to the -cc1 job, and that gets propagated as a code gen option and into the PassManagerBuilder. I have left the current logic translating -flto to the -emit-llvm-bc option,