Re: [RFC] Replace Java with Go in default languages
On 11/11/2013 03:22 AM, Jeff Law wrote: > On 11/09/13 08:55, Andrew Haley wrote: >> On 11/09/2013 03:44 PM, Alec Teal wrote: >>> If Java must go, and it must have a replacement Ada makes sense. The >>> issues with Go (sadly, you guys are doing superb work) do make sense. >>> >>> I don't know enough about Java (the GCC front end and such) to know if >>> it should go, if it does go why should it be replaced? >> >> It always was very useful for detecting bugs in GCC: the code flow tends >> to trigger bugs that don't get detected by the usual GCC testsuites. > That's certaily been the case in the past, but I'm seeing less and less > of that now. If we can get coverage of the non-call-exceptions paths > and cut 15% off the build/test cycle, then I think it's worth it. > > I'd even be willing to explicitly make this a trial and reinstate GCJ if > we find that GCJ is catching problems not caught by the existing default > language & runtime systems. > > Andrew -- my big question is what's the state of OpenJDK for other > architectures. The most obvious being ARM(64), but in general, what's > the process for bootstrapping OpenJDK on a new target It's no different from porting GCC/libc. You have to write an assembler back end, the native parts of the runtime library, a bytecode interpreter, relocs for the runtime linker, and the compiler back end. Call it two programmer-years to get something decent working. > and is GCJ an integral part of that process. We have used GCJ in the past when porting OpenJDK because OpenJDK wasn't cross-compilable, but that's fixed now: we can cross-compile from a host which already has OpenJDK. So we don't need GCJ for that. Andrew.
Re: Vectorizer/alignment
On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving
wrote:
> That didn't do it. What was the rationale w.r.t. to the relation
> between the vectorized sequenced and/or the alignment (I think these
> things are actually 2 separate things..) and the common block?!
We cannot adjust the alignment of a common block as we don't know
which common block the linker will pick in the end. We can (and do)
adjust the alignment of global variables though. And C++ defaults
to -fno-common.
In general when asking optimization questions it helps to provide
a testcase that can be compiled - otherwise you just provoke
random guesses (like mine) ;)
Richard.
> Hendrik
>
> On Fri, Nov 8, 2013 at 9:44 AM, Richard Biener
> wrote:
>> Hendrik Greving wrote:
>>>The code for a simple loop like
>>>
>>>for (i = 0; i < LENGTH-1; i++) {
>>>g_c[i] = g_a[i] + g_b[i];
>>>}
>>>
>>>looks good for g++ (4.9.0 20131028 (experimental)) (-O3 core-avx2)
>>>
>>>.L2:
>>>vmovdqa g_a(%rax), %ymm0 # 26 *movv8si_internal/2 [length = 8]
>>>vpaddd g_b(%rax), %ymm0, %ymm0 # 27 *addv8si3/2 [length = 8]
>>>addq $32, %rax # 29 *adddi_1/1 [length = 4]
>>>vmovaps %ymm0, g_c-32(%rax) # 28 *movv8si_internal/3 [length = 8]
>>>cmpq $39968, %rax # 31 *cmpdi_1/1 [length = 6]
>>>jne .L2 # 32 *jcc_1 [length = 2]
>>>
>>>but for gcc, I'm getting
>>>
>>>.L4:
>>>vmovdqu (%rsi,%rax), %xmm0 # 156 sse2_loaddquv16qi [length = 5]
>>>vinserti128 $0x1, 16(%rsi,%rax), %ymm0, %ymm0 # 157
>>>avx_vec_concatv32qi/1 [length = 8]
>>>addl $1, %edx # 161 *addsi_1/1 [length = 3]
>>>vpaddd (%rdi,%rax), %ymm0, %ymm0 # 158 *addv8si3/2 [length = 5]
>>>vmovups %xmm0, (%rcx,%rax) # 412 *movv16qi_internal/3 [length = 5]
>>>vextracti128 $0x1, %ymm0, 16(%rcx,%rax) # 160 vec_extract_hi_v32qi/2
>>>[length = 8]
>>>addq $32, %rax # 162 *adddi_1/1 [length = 4]
>>>cmpl $1248, %edx # 164 *cmpsi_1/1 [length = 6]
>>>jbe .L4 # 165 *jcc_1 [length = 2]
>>>
>>>unless I add "__attribute__ ((aligned (64)));" g_a, g_b, g_c.
>>>
>>>2 questions: Does C have different alignment requirements/specs than
>>>C++ (I don't think so)?
>>
>> Try -fno-common
>>
>> Richard.
>>
>> But if so, why does gcc not just align the
>>>arrays (they are in the same module in my example...)? Let aside the
>>>alignment question, why not just do avx2 (ymm) moves as g++ does?
>>>
>>>Guess my question is, is this a bug or a feature?
>>>
>>>Thanks,
>>>Regards,
>>>Hendrik
>>
>>
Re: How can I tune gcc to move up simple common subexpression?
On Fri, Nov 8, 2013 at 9:21 PM, Jeff Law wrote:
> On 11/08/13 02:28, Konstantin Vladimirov wrote:
>>
>> typedef struct
>> {
>>unsigned prev;
>>unsigned next;
>> } foo_t;
>>
>> void
>> foo( unsigned x, unsigned y)
>>{
>> foo_t *ptr = (foo_t *)((void *)x);
>>
>> if (y != 0)
>>{
>> ptr->prev = y;
>> ptr->next = x;
>> }
>> else
>> {
>> ptr->prev = 0; /* or explicitly ptr->prev = y; no difference */
>> ptr->next = 0;
>> }
>> }
>
> Umm, you can't hoist ptr->prev before the conditional because that would
> change the meaning of this code.
We test y != 0 and thus know that y == 0 in the else block. Thus we can
do
ptr->prev = y;
if (y != 0)
ptr->next = x;
else
ptr->next = 0;
note that we already transform
if (y != 0)
...
else
ptr->prev = y;
to ptr->prev = 0 AFAIK.
Richard.
>
> I think you wanted the conditional to test y == 0 which exposes the code
> hoisting opportunity for the ptr->prev assignment. Once you fix the
> testcase the code in jump2 will hoist the assignment resulting in:
>
>
>
>
>
> .cfi_startproc
>
> testl %esi, %esi
> movl%edi, %eax
> movl$0, (%edi)
>
> je .L5
> movl$0, 4(%rax)
> ret
> .p2align 4,,10
> .p2align 3
>
> .L5:
> movl%edi, 4(%rax)
> ret
> .cfi_endproc
>
>
> Jeff
Re: Vectorizer/alignment
On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: > On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving > wrote: > > That didn't do it. What was the rationale w.r.t. to the relation > > between the vectorized sequenced and/or the alignment (I think these > > things are actually 2 separate things..) and the common block?! > > We cannot adjust the alignment of a common block as we don't know > which common block the linker will pick in the end. We can (and do) > adjust the alignment of global variables though. And C++ defaults > to -fno-common. > > In general when asking optimization questions it helps to provide > a testcase that can be compiled - otherwise you just provoke > random guesses (like mine) ;) Well, we had the discussion about turning -fno-common by default for C as well, I think it wouldn't hurt and let people use -fcommon if they need it. Jakub
Re: Vectorizer/alignment
On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote: > On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: >> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving >> wrote: >> > That didn't do it. What was the rationale w.r.t. to the relation >> > between the vectorized sequenced and/or the alignment (I think these >> > things are actually 2 separate things..) and the common block?! >> >> We cannot adjust the alignment of a common block as we don't know >> which common block the linker will pick in the end. We can (and do) >> adjust the alignment of global variables though. And C++ defaults >> to -fno-common. >> >> In general when asking optimization questions it helps to provide >> a testcase that can be compiled - otherwise you just provoke >> random guesses (like mine) ;) > > Well, we had the discussion about turning -fno-common by default for C as > well, I think it wouldn't hurt and let people use -fcommon if they need it. Yeah, so ... shall we just do it? Maybe just for a selected set of targets (based on OS?)? Richard. > Jakub
Re: Vectorizer/alignment
On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote: > On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote: > > On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: > >> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving > >> wrote: > >> > That didn't do it. What was the rationale w.r.t. to the relation > >> > between the vectorized sequenced and/or the alignment (I think these > >> > things are actually 2 separate things..) and the common block?! > >> > >> We cannot adjust the alignment of a common block as we don't know > >> which common block the linker will pick in the end. We can (and do) > >> adjust the alignment of global variables though. And C++ defaults > >> to -fno-common. > >> > >> In general when asking optimization questions it helps to provide > >> a testcase that can be compiled - otherwise you just provoke > >> random guesses (like mine) ;) > > > > Well, we had the discussion about turning -fno-common by default for C as > > well, I think it wouldn't hurt and let people use -fcommon if they need it. > > Yeah, so ... shall we just do it? Maybe just for a selected set of > targets (based on OS?)? I vote for it. Perhaps with the exception when the variables are also weak, this worst case results in a link time failure which is easily fixable by adding -fcommon where really required, and in the usual case (dynamic linking) it is limited to the each package individually, if we document this in porting_to.html, I think changing the default is fine. But I guess it would be nice to hear more voices. Jakub
Re: Vectorizer/alignment
On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek wrote: > On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote: >> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote: >> > On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: >> >> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving >> >> wrote: >> >> > That didn't do it. What was the rationale w.r.t. to the relation >> >> > between the vectorized sequenced and/or the alignment (I think these >> >> > things are actually 2 separate things..) and the common block?! >> >> >> >> We cannot adjust the alignment of a common block as we don't know >> >> which common block the linker will pick in the end. We can (and do) >> >> adjust the alignment of global variables though. And C++ defaults >> >> to -fno-common. >> >> >> >> In general when asking optimization questions it helps to provide >> >> a testcase that can be compiled - otherwise you just provoke >> >> random guesses (like mine) ;) >> > >> > Well, we had the discussion about turning -fno-common by default for C as >> > well, I think it wouldn't hurt and let people use -fcommon if they need it. >> >> Yeah, so ... shall we just do it? Maybe just for a selected set of >> targets (based on OS?)? > > I vote for it. Perhaps with the exception when the variables are also weak, > this worst case results in a link time failure which is easily fixable by > adding -fcommon where really required, and in the usual case (dynamic > linking) it is limited to the each package individually, if we document this > in porting_to.html, I think changing the default is fine. > > But I guess it would be nice to hear more voices. Most fallout will be from headers that fail to declare variables as 'extern' (IIRC SPEC CPU 2000 has tons of that). It also hides bugs where one unit has 'int x' and one 'float x' (SPEC CPU 2006, LTO diagnoses this). I suppose targets without .bss section support should not switch (that is, targets not defining BSS_SECTION_ASM_OP or ASM_OUTPUT_ALIGNED_BSS). Richard. > Jakub
Re: [RFC] Replace Java with Go in default languages
Jeff Law writes: > Thoughts or comments? If noone tests java completely then it will quickly bitrot won't it? So ideally some bot would still regularly build/test it. If you don't do that you could as well just remove the code. The underlying problem seems to be the requirement for each contributor to run all the tests themselves. Over time the gcc test suite has become longer and longer, so it becomes a bigger burden. But then they still don't test everything, because of optional components (e.g. not everyone has Ada installed). Also some tests are just unreliable and do not give good results. Perhaps it would make more sense to just split the required tests : - quick tests everyone is expected to run before commit (bootstrap + test suite <10/20/30min?) That could be some subset of what runs today. Maybe bootstrap and most of the C/C++ test suite. - This should be only tests that always pass, not the usual noise that is there today (e.g. not that guality random generator) - longer tests that run in centralized bots - bots automatically bisect regressions - clear policies that if someone causes a bot regression they are on the hook to fix it in a given time, or the patch gets reverted. - Get rid of all tests that are not reliable. - With bots it would be also quite feasible to have even longer tests, that run hours. For example you could add more slow static code analysis steps. - With bots you can also have nice central dash boards that give the current state, instead of the current "hunt random message on gcc-testresults" -Andi
Re: [RFC] Replace Java with Go in default languages
On Mon, Nov 11, 2013 at 9:38 AM, Andi Kleen wrote: > Jeff Law writes: > >> Thoughts or comments? > > If noone tests java completely then it will quickly bitrot won't it? > > So ideally some bot would still regularly build/test it. > If you don't do that you could as well just remove the code. > > The underlying problem seems to be the requirement for each > contributor to run all the tests themselves. Over time the gcc > test suite has become longer and longer, so it becomes a bigger > burden. But then they still don't test everything, because > of optional components (e.g. not everyone has Ada installed). > Also some tests are just unreliable and do not give good results. > > Perhaps it would make more sense to just split the required tests : > > - quick tests everyone is expected to run before commit (bootstrap + > test suite <10/20/30min?) > That could be some subset of what runs today. Maybe bootstrap > and most of the C/C++ test suite. > - This should be only tests that always pass, not the usual noise that > is there today (e.g. not that guality random generator) > - longer tests that run in centralized bots > - bots automatically bisect regressions > - clear policies that if someone causes a bot regression > they are on the hook to fix it in a given time, or the patch gets > reverted. > - Get rid of all tests that are not reliable. > - With bots it would be also quite feasible to have even > longer tests, that run hours. For example you could add > more slow static code analysis steps. > - With bots you can also have nice central dash boards that give the current > state, instead of the current "hunt random message on gcc-testresults" Yes. I've been wanting to implement something along these lines for a long time. The basic idea was to use coverage to create a subset of the full testsuite. Anything that covers N% of the coverage of the full testsuite. N would be chosen to guarantee a turnaround time of less than, say, 20 minutes for a full bootstrap+test. We'd use that as the required testing process for everyday development. Bots would run the full testsuite. Diego.
Re: [RFC] Replace Java with Go in default languages
On Mon, Nov 11, 2013 at 06:38:15AM -0800, Andi Kleen wrote: > Jeff Law writes: > > > Thoughts or comments? > > If noone tests java completely then it will quickly bitrot won't it? > > So ideally some bot would still regularly build/test it. > If you don't do that you could as well just remove the code. > > The underlying problem seems to be the requirement for each > contributor to run all the tests themselves. Over time the gcc > test suite has become longer and longer, so it becomes a bigger > burden. But then they still don't test everything, because > of optional components (e.g. not everyone has Ada installed). > Also some tests are just unreliable and do not give good results. > Also if patch breaks ia64 it will be hardly noticed. There already are plenty of machines at compile farm so problem lies in writing a bot. > Perhaps it would make more sense to just split the required tests : > > - quick tests everyone is expected to run before commit (bootstrap + > test suite <10/20/30min?) > That could be some subset of what runs today. Maybe bootstrap > and most of the C/C++ test suite. > - This should be only tests that always pass, not the usual noise that > is there today (e.g. not that guality random generator) > - longer tests that run in centralized bots > - bots automatically bisect regressions > - clear policies that if someone causes a bot regression > they are on the hook to fix it in a given time, or the patch gets > reverted. > - Get rid of all tests that are not reliable. > - With bots it would be also quite feasible to have even > longer tests, that run hours. For example you could add > more slow static code analysis steps. > - With bots you can also have nice central dash boards that give the current > state, instead of the current "hunt random message on gcc-testresults" > This also reminds me similar proposal of shifting burden of testcase writing to users. Problem with adding user testcase is paperwork, so there would be separate codebase with user tests. It would work that if in bugzilla there is a bug with a reliable reproducer then commiter add reproducer with bug number to database. It would trigger a bot to do bisection what change introduced problem. These will be checked by bots and when there is a failure on closed bug it will be reopened. Also having a bot would allow adding benchmarks that take hours until variance gets to reasonable level.
Re: [RFC] Replace Java with Go in default languages
On Mon, 11 Nov 2013, Ondrej Bilka wrote: > These will be checked by bots and when there is a failure on closed bug it > will be reopened. No, don't reopen old bugs unless it turns out the patch claimed to fix the bug didn't fix it at all, or needed to be reverted. Open new bugs when all you know is that the symptom is the same (but the cause is almost certainly different), and include a comment mentioning the previous fixed bug with the same symptom. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Replace Java with Go in default languages
On Mon, Nov 11, 2013 at 04:12:51PM +, Joseph S. Myers wrote: > On Mon, 11 Nov 2013, Ondrej Bilka wrote: > > > These will be checked by bots and when there is a failure on closed bug it > > will be reopened. > > No, don't reopen old bugs unless it turns out the patch claimed to fix the > bug didn't fix it at all, or needed to be reverted. Open new bugs when > all you know is that the symptom is the same (but the cause is almost > certainly different), and include a comment mentioning the previous fixed > bug with the same symptom. > Also possible, main idea is to keep context. As original author is likely most familiar with relevant code what about copying a cc list of original bug?
Re: Question about overloaded operators
On 11/10/2013 07:58 PM, Iyer, Balaji V wrote: Semi crazy thought...If I do something like a string compare for the operation after operator toward the end of the function, will I get what I want? I guess another way to ask this is, will a '+' operation, for example, be mapped to a function ending in something other than "operator+" If you're specifically looking for operator+, you can compare the name to ansi_opname[PLUS_EXPR]. Jason
Re: [RFC] Replace Java with Go in default languages
On 11/11/13 07:38, Andi Kleen wrote: Jeff Law writes: Thoughts or comments? If noone tests java completely then it will quickly bitrot won't it? So ideally some bot would still regularly build/test it. If you don't do that you could as well just remove the code. There's no reason to remove the front-end. It's not much different than the situation with Ada, or how we deal with backends. If bitrot appears, but goes unnoticed for long periods of time, then that's an indication bits need to be removed. If bitrot appears and is fixed regularly, that's an indication that building & testing Java should continue to be part of the standard submission process. Perhaps it would make more sense to just split the required tests : [ ... ] You could easily look at moving Java out of the required languages to build/test as one step in this direction. Jeff
Re: Vectorizer/alignment
On 11/11/2013 11:57 PM, Richard Biener wrote: > On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek wrote: >> On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote: >>> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote: On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: > On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving > wrote: >> That didn't do it. What was the rationale w.r.t. to the relation >> between the vectorized sequenced and/or the alignment (I think these >> things are actually 2 separate things..) and the common block?! > > We cannot adjust the alignment of a common block as we don't know > which common block the linker will pick in the end. We can (and do) > adjust the alignment of global variables though. And C++ defaults > to -fno-common. > > In general when asking optimization questions it helps to provide > a testcase that can be compiled - otherwise you just provoke > random guesses (like mine) ;) Well, we had the discussion about turning -fno-common by default for C as well, I think it wouldn't hurt and let people use -fcommon if they need it. >>> >>> Yeah, so ... shall we just do it? Maybe just for a selected set of >>> targets (based on OS?)? >> >> I vote for it. Perhaps with the exception when the variables are also weak, >> this worst case results in a link time failure which is easily fixable by >> adding -fcommon where really required, and in the usual case (dynamic >> linking) it is limited to the each package individually, if we document this >> in porting_to.html, I think changing the default is fine. >> >> But I guess it would be nice to hear more voices. > > Most fallout will be from headers that fail to declare variables > as 'extern' (IIRC SPEC CPU 2000 has tons of that). It also > hides bugs where one unit has 'int x' and one 'float x' (SPEC CPU 2006, > LTO diagnoses this). It's for reasons like this that I'd not be especially comfortable changing the default of -fcommon for c89 (or gnu89, our default). I think we'd be ok changing the default for c99+, as that implies a certain "recentness" about the program under compilation, which to me implies they ought to know better. > > I suppose targets without .bss section support should not switch > (that is, targets not defining BSS_SECTION_ASM_OP or > ASM_OUTPUT_ALIGNED_BSS). Good point. I don't expect that we have many of those left, but if any do still exist... r~
Re: [RFC] Replace Java with Go in default languages
Am 11.11.2013 11:06, schrieb Andrew Haley: > On 11/11/2013 03:22 AM, Jeff Law wrote: >> On 11/09/13 08:55, Andrew Haley wrote: >>> On 11/09/2013 03:44 PM, Alec Teal wrote: If Java must go, and it must have a replacement Ada makes sense. The issues with Go (sadly, you guys are doing superb work) do make sense. I don't know enough about Java (the GCC front end and such) to know if it should go, if it does go why should it be replaced? >>> >>> It always was very useful for detecting bugs in GCC: the code flow tends >>> to trigger bugs that don't get detected by the usual GCC testsuites. >> That's certaily been the case in the past, but I'm seeing less and less >> of that now. If we can get coverage of the non-call-exceptions paths >> and cut 15% off the build/test cycle, then I think it's worth it. >> >> I'd even be willing to explicitly make this a trial and reinstate GCJ if >> we find that GCJ is catching problems not caught by the existing default >> language & runtime systems. >> >> Andrew -- my big question is what's the state of OpenJDK for other >> architectures. The most obvious being ARM(64), but in general, what's >> the process for bootstrapping OpenJDK on a new target > > It's no different from porting GCC/libc. You have to write an > assembler back end, the native parts of the runtime library, a > bytecode interpreter, relocs for the runtime linker, and the compiler > back end. Call it two programmer-years to get something decent > working. > >> and is GCJ an integral part of that process. > > We have used GCJ in the past when porting OpenJDK because OpenJDK > wasn't cross-compilable, but that's fixed now: we can cross-compile > from a host which already has OpenJDK. So we don't need GCJ for that. that's only partly true. Sure, when using an unreleased OpenJDK snapshot (leading to OpenJDK 8), then you are probably correct, however doing that for a released version of OpenJDK, it is still needed. At least for me, getting a GCJ working for AArch64, and then using it to build the OpenJDK Zero port on AArch64 did go well. And not only that, GCJ is still working on architectures where the OpenJDK Zero port stops working now, like mips, mipsel, s390, and where the upstream Hotspot isn't working anymore (sparc, sparc64). Matthias
Re: Vectorizer/alignment
On Mon, Nov 11, 2013 at 3:56 PM, Richard Henderson wrote: >> I suppose targets without .bss section support should not switch >> (that is, targets not defining BSS_SECTION_ASM_OP or >> ASM_OUTPUT_ALIGNED_BSS). > > Good point. I don't expect that we have many of those left, but > if any do still exist... AIX XCOFF, although it probably can be changed to explicitly use a BSS section. - David
Re: [RFC] Replace Java with Go in default languages
Am 09.11.2013 01:24, schrieb Ian Lance Taylor: > On Fri, Nov 8, 2013 at 2:21 PM, Jeff Law wrote: >> >> So instead of proposing that we just remove Java from the default languags, >> I propose that we replace Java with Go. > > I'm certainly in favor of removing Java from the set of default > languages. > > I'm less sure about adding Go. > > Right now Go does not build on a range of targets, notably including > Windows, MacOS, AIX, and most embedded systems. We would have to > disable it by default on targets that are not supported, which is > straightforward (we already have rules to disable java on targets it > does not support). But to the extent that there are options like > -fnon-call-exceptions that are tested primarily by Java and Go, we > would get less coverage of those options, since we would not test them > on systems that Java supports but Go does not. > > More seriously, the Go sources live in a separate repository, and are > copied to the GCC repo. In practice this means that when Go breaks, > it can't be fixed until I am online to fix it. I don't think it would > be good for GCC for a bootstrap break to depend on me. Of course we > could change the rules somewhat, and let people commit changes to the > Go parts of the GCC repo which I would then have to copy out. But > it's something to think about. One more thing for posting test results with multilib enabled: It would be nice if libgo would use dejagnu and honor RUNTESTFLAGS for multilib test runs. Matthias
Re: [RFC] Replace Java with Go in default languages
Am 08.11.2013 23:21, schrieb Jeff Law: > > > GCJ has, IMHO, moved from active development into a deep maintenance mode. > I > suspect this is largely due to the change of focus of key developers to > OpenJDK > and other projects. GCJ played a role in bootstrapping OpenJDK, both > technically and politically and had OpenJDK not happened, I suspect GCJ would > still be under active development. > > The last news item related to Java was 2009 and scanning the ChangeLog doesn't > show significant project activity (~14 changes in 2013, most of which look > like > routine maintenance in the language front-end. There's even fewer changes > occurring in the runtime system. GCJ still plays this role for OpenJDK 6 and OpenJDK 7. > I did some benchmarking using one of my slower systems (primarily because my > faster systems are used for real work). It's an older quad machine, but > should > give us a reasonable feel for how expensive java is to the bootstrap & > regression testing process. > > A default languages bootstrap takes 67 minutes on that box (-j4). The times > were consistent to within 20 seconds. Disabling java brings that time down to > 51 minutes, again with a variance of around 20 seconds. That means roughly 25% > of the time to bootstrap is Java. These times include the time to build the libjava dependencies, boehm-gc, libffi and zlib. At least these should be measured separately. boehm-gc is used too when configured with --enable-objc-gc. libffi (?) and zlib are used when building Go, so these times will be re-added when building the Go frontend. > I didn't measure total testing time -- just the time to test Java, where it > clocks in at 7 minutes (again -j4, though it's clearly not doing much in > parallel). > > Clearly bootstrapping and testing Java is expensive. It's better than a while > back (thanks to removing the static library build), but it's still a > significant > component of the bootstrap & test cycle we all do regularly. > > We discussed removing libjava extensively in 2008, but never moved forward. > It's not entirely clear why from reviewing the thread. Additionally, I think > the > landscape around OpenJDK is a bit different now than then and thus it's time > to > revisit. > > So instead of proposing that we just remove Java from the default languags, I > propose that we replace Java with Go. > > Go uses -fnon-call-exceptions which is one of the things that was a bit unique > about GCJ and Go appears to have a much more vibrant developer and user > community than GCJ. So we get the -fnon-call-exceptions testing we want and > we're actually building a front-end that a larger community cares about. > > A bootstrap with Go replacing Java clocks in at 56 minutes. So we're still > getting most of the improvement in bootstrap times. > > Testing Go (compiler & runtime) takes about a minute longer than libjava (it's > doing more in parallel, so serially Go would be considerably longer in > testing). > > Clearly switching from libjava to go would be a significant improvement in the > bootstrap and regression test cycle. On the box I tested we'd see roughly at > 15% improvement and we'd still get testing of -fnon-call-exceptions. assuming that you did these tests on amd64, it helps to build the default libjava multilib variant only. In the past I did propose to do that by default. Back then people did think this wasn't necessary when cutting the build time in half by disabling the static libjava build by default. the libjava build itself does parallelize well except for building libgcj-tools, so a bit of speed-up could be gained there too. the libjava tests currently don't run parallelized, however from my expericence these tests are not the longest running ones. Again, maybe don't count the times for the boehm-gc and libffi tests. Matthias
Re: libgo and DejaGNU
On Mon, Nov 11, 2013 at 1:32 PM, Matthias Klose wrote: > > One more thing for posting test results with multilib enabled: It would be > nice > if libgo would use dejagnu and honor RUNTESTFLAGS for multilib test runs. What does libstdc++ do for RUNTESTFLAGS? Ian
Re: Vectorizer/alignment
Ok, thanks, that explains it... Apparently x86 splits the vector movs
into 2 in
ix86_expand_vector_move_misalign->ix86_avx256_split_vector_move_misalign.
But I wanted to mention that e.g. icc, despite also putting g_a, g_b,
g_c into .comm, actually generates AVX2 vmovdqu using ymm...
Examples:
foo.c:
#include
#include
#include "foo.h"
int g_a[LENGTH];
int g_b[LENGTH];
int g_c[LENGTH];
void
foo()
{
int i ;
for (i = 0; i < LENGTH; i++) {
g_c[i] = g_a[i] + g_b[i];
}
}
icc:
icc/13.1.3/bin/icc -S -O3 -march=core-avx2 foo.c -v -save-temps -vec-report=2
gcc:
gcc -S -O3 -march=core-avx2 foo.c -ftree-vectorizer-verbose=1 -dp -v -da
On Mon, Nov 11, 2013 at 1:31 PM, David Edelsohn wrote:
> On Mon, Nov 11, 2013 at 3:56 PM, Richard Henderson wrote:
>
>>> I suppose targets without .bss section support should not switch
>>> (that is, targets not defining BSS_SECTION_ASM_OP or
>>> ASM_OUTPUT_ALIGNED_BSS).
>>
>> Good point. I don't expect that we have many of those left, but
>> if any do still exist...
>
> AIX XCOFF, although it probably can be changed to explicitly use a BSS
> section.
>
> - David
Re: Vectorizer/alignment
On Mon, Nov 11, 2013 at 2:48 PM, Hendrik Greving
wrote:
> Ok, thanks, that explains it... Apparently x86 splits the vector movs
> into 2 in
> ix86_expand_vector_move_misalign->ix86_avx256_split_vector_move_misalign.
> But I wanted to mention that e.g. icc, despite also putting g_a, g_b,
> g_c into .comm, actually generates AVX2 vmovdqu using ymm...
>
> Examples:
>
> foo.c:
>
> #include
> #include
> #include "foo.h"
>
> int g_a[LENGTH];
> int g_b[LENGTH];
> int g_c[LENGTH];
> void
> foo()
> {
> int i ;
> for (i = 0; i < LENGTH; i++) {
> g_c[i] = g_a[i] + g_b[i];
> }
> }
>
> icc:
> icc/13.1.3/bin/icc -S -O3 -march=core-avx2 foo.c -v -save-temps -vec-report=2
>
> gcc:
> gcc -S -O3 -march=core-avx2 foo.c -ftree-vectorizer-verbose=1 -dp -v -da
>
>
Please open a bug. We will fix it.
Thanks.
--
H.J.
Re: DWARF and atomic types
On 11/08/13 05:36, Joseph S. Myers wrote: I realised that the C11 atomics changes didn't do anything to record atomic types as such in DWARF debug info - then found that DWARF4 didn't provide a way to specify the C11 _Atomic qualifier at all. Could someone working with the DWARF committee get an appropriate tag into the next version of DWARF? (I've filed bug 59051 for the lack of use of DW_tag_restrict_type for restricted pointers.) Hi Joseph -- Can you go to http://dwarfstd.org/Comment.php and submit a description of the change in C11 and a request that this be added. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [RFC] Replace Java with Go in default languages
On 11/11/13 14:48, Matthias Klose wrote: The last news item related to Java was 2009 and scanning the ChangeLog doesn't show significant project activity (~14 changes in 2013, most of which look like routine maintenance in the language front-end. There's even fewer changes occurring in the runtime system. GCJ still plays this role for OpenJDK 6 and OpenJDK 7. I thought OpenJDK was in a state where it no longer needed GCJ -- can you explain precisely how GCJ is still used here? These times include the time to build the libjava dependencies, boehm-gc, libffi and zlib. At least these should be measured separately. boehm-gc is used too when configured with --enable-objc-gc. libffi (?) and zlib are used when building Go, so these times will be re-added when building the Go frontend. No need to re-add, the times for anything Go depended on are accounted for. However, we're now looking at replacing Java with Ada for various reasons. Clearly switching from libjava to go would be a significant improvement in the bootstrap and regression test cycle. On the box I tested we'd see roughly at 15% improvement and we'd still get testing of -fnon-call-exceptions. assuming that you did these tests on amd64, it helps to build the default libjava multilib variant only. In the past I did propose to do that by default. Back then people did think this wasn't necessary when cutting the build time in half by disabling the static libjava build by default. the libjava build itself does parallelize well except for building libgcj-tools, so a bit of speed-up could be gained there too. Yes, the libjava build is embarrasingly not parallel. I don't see that anyone is likely to try and tackle that problem. the libjava tests currently don't run parallelized, however from my expericence these tests are not the longest running ones. Again, maybe don't count the times for the boehm-gc and libffi tests. The testsuite is a relatively small component -- if you read my message closely you'd see that testing libjava is roughly requivalent to testing go (front-end + runtime) and according to Eric testing libjava is roughly equivalent to testing Ada. Reducing the build time and focusing on front-ends with a higher impact is really the issue we're trying to resolve. I'll note we're not talking about removing java from GCC, just removing it from the set of things that have to be built & tested for each checkin. One could even consider another alternative -- building/testing java optional during stage1, required during stage3. Jeff
Re: Vectorizer/alignment
I've filed bug 59084. I think it actually might affect the same x86
backend stuff as bug 41464.
Hendrik
On Mon, Nov 11, 2013 at 4:00 PM, H.J. Lu wrote:
> On Mon, Nov 11, 2013 at 2:48 PM, Hendrik Greving
> wrote:
>> Ok, thanks, that explains it... Apparently x86 splits the vector movs
>> into 2 in
>> ix86_expand_vector_move_misalign->ix86_avx256_split_vector_move_misalign.
>> But I wanted to mention that e.g. icc, despite also putting g_a, g_b,
>> g_c into .comm, actually generates AVX2 vmovdqu using ymm...
>>
>> Examples:
>>
>> foo.c:
>>
>> #include
>> #include
>> #include "foo.h"
>>
>> int g_a[LENGTH];
>> int g_b[LENGTH];
>> int g_c[LENGTH];
>> void
>> foo()
>> {
>> int i ;
>> for (i = 0; i < LENGTH; i++) {
>> g_c[i] = g_a[i] + g_b[i];
>> }
>> }
>>
>> icc:
>> icc/13.1.3/bin/icc -S -O3 -march=core-avx2 foo.c -v -save-temps -vec-report=2
>>
>> gcc:
>> gcc -S -O3 -march=core-avx2 foo.c -ftree-vectorizer-verbose=1 -dp -v -da
>>
>>
>
> Please open a bug. We will fix it.
>
> Thanks.
>
> --
> H.J.
Re: [RFC] Replace Java with Go in default languages
On 11/09/13 04:12, Eric Botcazou wrote: Right now Go does not build on a range of targets, notably including Windows, MacOS, AIX, and most embedded systems. We would have to disable it by default on targets that are not supported, which is straightforward (we already have rules to disable java on targets it does not support). But to the extent that there are options like -fnon-call-exceptions that are tested primarily by Java and Go, we would get less coverage of those options, since we would not test them on systems that Java supports but Go does not. Let me make the case for Ada here: it's a general purpose, highly portable language, which is regularly built and tested on a significant range of platforms (I personally test it on x86/Linux, x86-64/Linux, PowerPC/Linux, IA-64/Linux, SPARC/Solaris and SPARC64/Solaris). It exercices some features of the compiler that aren't exercised by other languages and stretches some common features much more than the other languages. It turns out that it also enables -fnon-call-exceptions by default. It seamlessly works with LTO. While the fact that a big part of the front-end is written in Ada could be seen as an annoyance (although GNAT has been largely available for about a decade on many systems), it can also be seen a boon; for example, a LTO bootstrap with Ada enabled really exercises cross-language optimizations. Bootstrapping with Ada is marginally slower than with Go (a few percents) and the testsuite is small (4-way parallelizable, testing time of 6 minutes on a fast machine). From what I can see, bootstrapping with Ada is slower than bootstapping with Java, by around 15%. Again this is on one of my slower boxes, but the results clearly show building Ada & its runtime takes a considerable amount of time: default languages:67 minutes default - java: 51 minutes default - java + go: 56 minutes default - java + ada: 77 minutes Some of this might be building Ada and its runtime during all three stages. Contrast to Java which builds the front-end during stage2/stage3 and the runtime just in stage3. Hard to justify switching from Java to Ada given those results if one of the key goals is to reduce waiting time. jeff
Re: [RFC] Replace Java with Go in default languages
> From what I can see, bootstrapping with Ada is slower than bootstapping > with Java, by around 15%. Again this is on one of my slower boxes, but > the results clearly show building Ada & its runtime takes a considerable > amount of time: > > default languages:67 minutes > default - java: 51 minutes > default - java + go: 56 minutes > default - java + ada: 77 minutes With what checking options? Weird, on my not so fast x86-64 machine, the 3rd item takes 40 min and the 4th 42 min with yes,rtl checking, so a difference of 21 min on yours is unexpected. > Some of this might be building Ada and its runtime during all three > stages. Contrast to Java which builds the front-end during > stage2/stage3 and the runtime just in stage3. The Ada runtime is only built during stage3 too. > Hard to justify switching from Java to Ada given those results if one of > the key goals is to reduce waiting time. If everyone has the same figures as you, I cannot disagree. -- Eric Botcazou
Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
[text-only] On Sun, Nov 10, 2013 at 10:34 PM, FX wrote: >> Unfortunately, we are not able to keep up with the old kernels. >> Two possible ways to go: >> - disable libsanitizer on older kernels >> - someone needs to work with us in upstream repository (llvm) to keep the >> code old-kernel-compatible > > (It appears to be not only kernel, but binutils.) > > I think, at least the following should be done: > > - identify and document the minimal requirements Agree. From our side we can only guarantee Ubuntu 12.04 and higher. --kcc > - test for necessary features at compilation time (we have full autoconf, > presence of crucial headers should be tested) and issue a meaningful error > message if they are not found > - ideally, but I know it is more work: disable libsanitizer automatically > from toplevel configure if requirements are not met > > This is what is done for dependencies of all default parts of the compiler, > as far as I can tell. > > FX
Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote: > On Sun, Nov 10, 2013 at 10:34 PM, FX wrote: > > > > Unfortunately, we are not able to keep up with the old kernels. > > > Two possible ways to go: > > > - disable libsanitizer on older kernels > > > - someone needs to work with us in upstream repository (llvm) to keep > > the code old-kernel-compatible > > > > (It appears to be not only kernel, but binutils.) > > > > I think, at least the following should be done: > > > > - identify and document the minimal requirements > > > > Agree. From our side we can only guarantee Ubuntu 12.04 and higher. For making sure libsanitizer at least compiles, just installing /usr/include/ trees from a couple of important still supported distributions from various eras and just using -isystem /path/to/distro1/usr/include/ as additional (very quick) test of building the libraries on your bots wouldn't be IMHO that difficult. Jakub
