similar to: [LLVMdev] [RFC] 3-bit Waymarking

Displaying 20 results from an estimated 700 matches similar to: "[LLVMdev] [RFC] 3-bit Waymarking"

2014 Apr 22
2
[LLVMdev] [RFC] 3-bit Waymarking
On 4/22/14, Chris Lattner <clattner at apple.com> wrote: > > On Apr 22, 2014, at 7:28 AM, Gabor Greif <ggreif at gmail.com> wrote: > >> Hi devs, >> >> after my intentionally "playful" EuroLLVM presentation (*) I think it >> would be time to get serious about merging to ToT. But we should >> probably find out whether an optimized
2020 Apr 01
2
[RFC] Removing Waymarking from Use.
Hi llvm-dev, I have a patch open for review that removes waymarking https://reviews.llvm.org/D77144. This patch removes waymarking and replaces it with storing a pointer to the User in the Use. when compiling the CTMark tests of the test suite, this give an average of +1.8% max memory use and -1.1% compile time. Removing Waymarking also simplifies the code of Use and User. Any thought?
2020 Apr 03
2
[RFC] Removing Waymarking from Use.
I'm in favor for this change. I've also done some testing myself and noticed only about 1-2% increase of memory, in exchange for about 1-3% increase of speed. I can't say that a speedup of 3% (at most, and usually 1%), worth working for, this is a simple change, that give a lot more than this; especially simpler code path (also easier debugging). As part of my measurements, while
2020 Apr 04
2
[RFC] Removing Waymarking from Use.
> On Apr 3, 2020, at 11:06 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > >> >> >> Is it worth it? I think it is. But I am not sure I see the whole picture - >> are there low-memory systems that need to run LLVM on? >> >> I am not sure what needs to be done to approve such a fundamental change; >> especially when we
2020 Apr 14
2
[RFC] Removing Waymarking from Use.
Yes please. On Tue, Apr 14, 2020, 5:02 AM Tyker1 at outlook.com via llvm-dev < llvm-dev at lists.llvm.org> wrote: > a bit of time has passed and there to my knowledge still no strong > arguments against removing it. > is everyone OK to proceed with the removal ? > > Gauthier > ------------------------------ > *From:* Chris Lattner <clattner at nondot.org> >
2008 Apr 21
3
[LLVMdev] does llvm-gcc (4.2) build?
Hi all, can anybody confirm that llvm-gcc is broken? After following all the instructions, make gets stuck while: ggreif$ gmake gmake \ CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common " \ CONFIG_H="config.h auto-host.h
2008 Apr 15
6
[LLVMdev] PATCH: Use size reduction -- wave2
Hi All, here comes the patch for the second wave of Use class size reduction. I have included all the machinery that is needed, and it is *active*. The User* inside of Use is even sometimes NULL, but the algorithm is able to recover it. If there is a non-null User* present, then I am asserting that it equals the computed value. I did not receive feedback for the algorithmic part yet, so I
2012 Jul 13
2
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com>wrote: > > On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com> > wrote: > > > Benjamin Kramer wrote: > >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> > wrote: > >> > >>> Hi all, > >>> >
2008 Apr 21
0
[LLVMdev] does llvm-gcc (4.2) build?
On Mon, 21 Apr 2008, Gabor Greif wrote: > Hi all, > > can anybody confirm that llvm-gcc is broken? It builds for me on x86, darwin8 (svn rev: 50048). What are you using to configure it? Whenever I have had problems building llvm-gcc, I usually have to delete my install and obj dir, make clean llvm, and start over from the top. Its a pain, but it works usually. -Tanya > >
2012 Jul 13
2
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
Benjamin Kramer wrote: > On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > >> Hi all, >> >> I am in charge of the controlled introduction of clang into >> our builds at my workplace. Since all our tools must run from >> a ClearCase view for automatic dependency tracking, we have been >> biten by a Linux bug, and
2012 Jul 13
0
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > Hi all, > > I am in charge of the controlled introduction of clang into > our builds at my workplace. Since all our tools must run from > a ClearCase view for automatic dependency tracking, we have been > biten by a Linux bug, and readlink("/proc/self/exe", ...) gives >
2012 Jul 14
0
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
Chandler Carruth wrote: > On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com > <mailto:benny.kra at gmail.com>> wrote: > > > On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com > <mailto:gabor.greif at alcatel-lucent.com>> wrote: > > > Benjamin Kramer wrote: > >> On 13.07.2012,
2008 Apr 16
0
[LLVMdev] PATCH: Use size reduction -- wave2
Hi Gabor, Can you provide performance data for this? I'd like to know what affect these changes have on compile time. Thanks, Dan On Apr 15, 2008, at 3:32 PM, Gabor Greif wrote: > Hi All, > > here comes the patch for the second wave of Use class size reduction. > > I have included all the machinery that is needed, and it is > *active*. The User* inside of Use is even
2012 Jul 13
0
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > Benjamin Kramer wrote: >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: >> >>> Hi all, >>> >>> I am in charge of the controlled introduction of clang into >>> our builds at my workplace. Since all our tools must run
2013 Dec 05
3
[LLVMdev] Integrated 'as' for PowerPC by default?
Hi PPC folks, as of v3.3 the integrated assembler seems to work fine. But it is not on by default. What is the obstacle for this last step? Just curious, Gabor
2007 Jul 11
2
[LLVMdev] PATCH: regarding PR1546
I do not consider PR1546 closed just yet. What I mentioned in the PR was only two of ca. 140 Solaris failures. Most of them complain that llc cannot choose between C and MSIL output formats. The below prototypical patch corrects this type of failure. Is this the right way of handling it? Why does llc only fail on Solaris and not on Darwin? After I understood this problem I am happy to commit
2008 Apr 04
2
[LLVMdev] PATCH: Use size reduction -- wave1
heisenbug wrote: > On Apr 3, 10:53 pm, Gabor Greif <ga... at mac.com> wrote: > ... > > >>> 3) Make sure that make check and some reasonable subset of llvm-test >>> passes with this patch :) >>> >> I have never run llvm-test in the past. Is it just checking it out and >> following a readme? >> > > > After
2012 Jul 13
2
[LLVMdev] Dealing with a corrupted /proc/self/exe link
Hi all, I am in charge of the controlled introduction of clang into our builds at my workplace. Since all our tools must run from a ClearCase view for automatic dependency tracking, we have been biten by a Linux bug, and readlink("/proc/self/exe", ...) gives nonsensical results. So we need to introduce a configure option for disallowing this method of executable discovery (the other one
2008 Apr 04
0
[LLVMdev] PATCH: Use size reduction -- wave1
On Fri, 4 Apr 2008, heisenbug wrote: >> point taken. thanks! > > > Whatever I try I get something like this: > > ggreif$ cd MultiSource/ > ggreif$ make > make[2]: *** No rule to make target `Output/be.bc', needed by `Output/ > burg.linked.rbc'. Stop. > make[1]: *** [Burg/.makeall] Error 2 > make: *** [Applications/.makeall] Error 2 This is the
2008 Apr 04
3
[LLVMdev] PATCH: Use size reduction -- wave1
On Apr 4, 8:06 pm, heisenbug <ggr... at gmail.com> wrote: > On Apr 4, 7:51 pm, Török Edwin <edwinto... at gmail.com> wrote: > > > > > heisenbug wrote: > > > On Apr 3, 10:53 pm, Gabor Greif <ga... at mac.com> wrote: > > > ... > > > >>> 3) Make sure that make check and some reasonable subset of llvm-test > > >>>