On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote:> > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > > > dependencies for these at the moment since they seem to depend on some > > > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a > > > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches > > > > > > and refactors a large amount of the Mips calling convention code. What do > > > > > > you think? > > > > > > > > > > Can you give me an idea of how important these fixes are? My personal > > > > > feeling is that big fixes like this can sometimes be OK as long as they > > > > > are mostly contained to a specific target and that target isn't X86 > > > > > or ARM. > > > > > > > > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, > > > > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py > > > > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare > > > > corner cases (e.g. 128-bit float return values). > > > > > > It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions > > > there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm > > > happy to do so. > > > > > > Thanks. > > > > > > -eric > > > > I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running > > 'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35, > > and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed. > > I'm going to run as much ABI testing as possible on it this evening. > > I've successfully run the simple vararg test (passing 10 int's in varargs, passing them in a va_list, then printing each one) for all ABI's/endians and mixtures of GCC/Clang. > > I've also run the first 5,000 ABITestGen.py generated tests for all ABI's/Endians. Big-endian O32 shows a single failure involving small structures (this is not a regression). Big-endian N32 shows about a dozen failures that do not fail on the trunk but aren't regressions either. All other ABI's and Endians are passing successfully. Even with those big-endian N32 failures (which fail without the patches too), this status is a big improvement on the status without the patches so I'm inclined to think we should merge and fix the remaining issues in 3.5.2 (assuming we do one). > Tom: Is that ok with you? > David: Are you using big-endian N32 or N64? > > I'm running an event with some students for most of today. I'll check my emails when I can and I'll have my laptop but I probably won't be able to merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests running in the meantime.I will try to look at the patches today. I'm going to delay the release a week or so, because of all the merge requests I've received, so there is no rush. -Tom> > Apart from the ABI fixes mentioned above, the only patch I'm awaiting approval for is: > * r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.
On 26 Nov 2014, at 16:50, Tom Stellard <tom at stellard.net> wrote:> > On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote:...> I will try to look at the patches today. I'm going to delay the release a week > or so, because of all the merge requests I've received, so there is no rush.Hi Tom, I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base system. Apologies in advance for the long list. :) Enabling TLS support for PowerPC32: http://llvm.org/viewvc/llvm-project?rev=213960&view=rev [PowerPC] Support TLS on PPC32/ELF Patch by Justin Hibbits! Two changes needed for being able to link lldb 3.5.x against llvm 3.5.x: http://llvm.org/viewvc/llvm-project?rev=215352&view=rev AArch64: add support for dynamic-loader relocations LLD needs them, and it's good to be able to print them properly when our object dumpers encounter them. Patch by Daniel Stewart. http://llvm.org/viewvc/llvm-project?rev=216571&view=rev Fix some semantic usability issues with DynamicLibrary. This patch allows invalid DynamicLibrary instances to be constructed, and fixes the const-correctness of the isValid() method. Fixing a possible SIGILL problem on ARMv6 and lower, plus test: http://llvm.org/viewvc/llvm-project?rev=216989&view=rev Only emit movw on ARMv6T2+ Fix PR18364. Patch by Dimitry Andric. http://llvm.org/viewvc/llvm-project?rev=216990&view=rev Missing test from r216989 Fix assigning garbage to floats in some cases: http://llvm.org/viewvc/llvm-project?rev=217410&view=rev Set trunc store action to Expand for all X86 targets. When compiling without SSE2, isTruncStoreLegal(F64, F32) would return Legal, whereas with SSE2 it would return Expand. And since the Target doesn't seem to actually handle a truncstore for double -> float, it would just output a store of a full double in the space for a float hence overwriting other bits on the stack. Patch by Luqman Aden! Enabling armv6k for FreeBSD/ARM: http://llvm.org/viewvc/llvm-project?rev=217454&view=rev Use armv6k default for FreeBSD/ARM Patch by Andrew Turner. Downgrading a DWARF2 section error when .note sections are added to a .S file while debug info is on: http://llvm.org/viewvc/llvm-project?rev=218241&view=rev Downgrade DWARF2 section limit error to a warning We currently emit an error when trying to assemble a file with more than one section using DWARF2 debug info. This should be a warning instead, as the resulting file will still be usable, but with a degraded debug illusion. Fixing a very bad OOM condition when compiling certain programs with debug info on, plus test: http://llvm.org/viewvc/llvm-project?rev=221709&view=rev Totally forget deallocated SDNodes in SDDbgInfo. What would happen before that commit is that the SDDbgValues associated with a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep a map entry keyed by the SDNode pointer pointing to this list of invalidated SDDbgNodes. As the memory gets reused, the list might get wrongly associated with another new SDNode. As the SDDbgValues are cloned when they are transfered, this can lead to an exponential number of SDDbgValues being produced during DAGCombine like in http://llvm.org/bugs/show_bug.cgi?id=20893 Note that the previous behavior wasn't really buggy as the invalidation made sure that the SDDbgValues won't be used. This commit can be considered a memory optimization and as such is really hard to validate in a unit-test. http://llvm.org/viewvc/llvm-project?rev=221854&view=rev Add an assert and a test that verify r221709's fix. Enable AArch64 support for FreeBSD: http://llvm.org/viewvc/llvm-project?rev=221900&view=rev Hook up FreeBSD AArch64 support Patch from Andrew Turner. Partially fix FreeBSD boot2 size optimization regressions: http://llvm.org/viewvc/llvm-project?rev=222562&view=rev Disable header duplication at -Oz in loop-rotate pass. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141126/12b9bea8/attachment.sig>
On 26 Nov 2014, at 16:50, Tom Stellard <tom at stellard.net> wrote:> > On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote:...> I will try to look at the patches today. I'm going to delay the release a week > or so, because of all the merge requests I've received, so there is no rush.Hi Tom, Here is another rather important one, fresh off the commit list. Fix libapr apr_stat() miscompilation: http://llvm.org/viewvc/llvm-project?rev=222856&view=rev Revert "Added inst combine transforms for single bit tests from Chris's note" This reverts commit r210006, it miscompiled libapr which is used in who knows how many projects. A test has been added to ensure that we don't regress again. I'll work on a rewrite of what the optimization was trying to do later. -Dimitry
> -----Original Message----- > From: Tom Stellard [mailto:tom at stellard.net] > Sent: 26 November 2014 15:50 > To: Daniel Sanders > Cc: Eric Christopher; Dr D. Chisnall; LLVM Developers Mailing List > (llvmdev at cs.uiuc.edu) > Subject: Re: [LLVMdev] Proposed patches for Clang 3.5.1 > > On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > > > From: Daniel Sanders > > > Sent: 25 November 2014 17:39 > > > To: Eric Christopher; Tom Stellard > > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > > > I'd also like to propose the inclusion of the recent ABI fixes to the > Mips > > > > > > > target but I'm not sure this is a good idea. I'm having difficulty > sorting out the > > > > > > > dependencies for these at the moment since they seem to > depend on some > > > > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may > also be a > > > > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 > Clang patches > > > > > > > and refactors a large amount of the Mips calling convention code. > What do > > > > > > > you think? > > > > > > > > > > > > Can you give me an idea of how important these fixes are? My > personal > > > > > > feeling is that big fixes like this can sometimes be OK as long as they > > > > > > are mostly contained to a specific target and that target isn't X86 > > > > > > or ARM. > > > > > > > > > > Without them, the calling convention for big-endian 64-bit Mips > targets is very badly broken. Clang is generally consistent with itself, > > > > > but interlinking with GCC-compiled code doesn't work. When I started > on this work ~4500 of 5000 tests generated by ABITestGen.py > > > > > produced incorrect output when mixing > GCC and Clang objects. 32- > bit and little-endian Mips targets are ok except for a couple rare > > > > > corner cases (e.g. 128-bit float return values). > > > > > > > > It's likely possible to rewrite the patches so that they don't depend on > my other work. If you have any questions > > > > there or need me to stamp the rewrites as "what should happen if you > don't take my patches into account" I'm > > > > happy to do so. > > > > > > > > Thanks. > > > > > > > > -eric > > > > > > I believe I've managed to backport them to the release_35 branch but I > haven't re-tested them beyond running > > > 'ninja check-all' yet. The patches are currently at > https://github.com/dsandersimgtec/clang/commits/release_35, > > > and > https://github.com/dsandersimgtec/llvm/commits/release_35_proposed. > > > I'm going to run as much ABI testing as possible on it this evening. > > > > I've successfully run the simple vararg test (passing 10 int's in varargs, > passing them in a va_list, then printing each one) for all ABI's/endians and > mixtures of GCC/Clang. > > > > I've also run the first 5,000 ABITestGen.py generated tests for all > ABI's/Endians. Big-endian O32 shows a single failure involving small structures > (this is not a regression). Big-endian N32 shows about a dozen failures that > do not fail on the trunk but aren't regressions either. All other ABI's and > Endians are passing successfully. Even with those big-endian N32 failures > (which fail without the patches too), this status is a big improvement on the > status without the patches so I'm inclined to think we should merge and fix > the remaining issues in 3.5.2 (assuming we do one). > > Tom: Is that ok with you? > > David: Are you using big-endian N32 or N64? > > > > I'm running an event with some students for most of today. I'll check my > emails when I can and I'll have my laptop but I probably won't be able to > merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests > running in the meantime. > > I will try to look at the patches today. I'm going to delay the release a week > or so, because of all the merge requests I've received, so there is no rush.That's a relief :-). I'll see if I can fix the N32 issues that remain on this branch. So far, I've run the first 90,000 tests for each ABI/endian with only the failures explained above.> -Tom > > > > Apart from the ABI fixes mentioned above, the only patch I'm awaiting > approval for is: > > * r217257 - [mips] Change Feature-related types from unsigned to uint64_t > in MipsAsmParser. No functional changes. > > This one is OK, I didn't realize those were private functions, so there > shouldn't be an API impact.Thanks. Merged in r222875.
> > > I've successfully run the simple vararg test (passing 10 int's in varargs, > > passing them in a va_list, then printing each one) for all ABI's/endians and > > mixtures of GCC/Clang. > > > > > > I've also run the first 5,000 ABITestGen.py generated tests for all > > ABI's/Endians. Big-endian O32 shows a single failure involving small > structures > > (this is not a regression). Big-endian N32 shows about a dozen failures that > > do not fail on the trunk but aren't regressions either. All other ABI's and > > Endians are passing successfully. Even with those big-endian N32 failures > > (which fail without the patches too), this status is a big improvement on the > > status without the patches so I'm inclined to think we should merge and fix > > the remaining issues in 3.5.2 (assuming we do one). > > > Tom: Is that ok with you? > > > David: Are you using big-endian N32 or N64? > > > > > > I'm running an event with some students for most of today. I'll check my > > emails when I can and I'll have my laptop but I probably won't be able to > > merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests > > running in the meantime. > > > > I will try to look at the patches today. I'm going to delay the release a week > > or so, because of all the merge requests I've received, so there is no rush. > > That's a relief :-). I'll see if I can fix the N32 issues that remain on this branch. > > So far, I've run the first 90,000 tests for each ABI/endian with only the failures > explained above.Just a quick update. The big-endian N32 failures have turned out to be false-positives. According to the logs, a shell script was briefly unavailable when it tried to run these tests. I've re-run them and they pass now. The only failure I know of is the single big-endian O32 failure.
On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote:> On 26 Nov 2014, at 16:50, Tom Stellard <tom at stellard.net> wrote: > > > > On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > ... > > I will try to look at the patches today. I'm going to delay the release a week > > or so, because of all the merge requests I've received, so there is no rush. > > Hi Tom, > > I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base system. Apologies in advance for the long list. :) >Hi Dimitry, Can you cc the appropriate code owners to get their approval. It might help to send a separate email per code owner. Thanks, Tom> > Enabling TLS support for PowerPC32: > > http://llvm.org/viewvc/llvm-project?rev=213960&view=rev > > [PowerPC] Support TLS on PPC32/ELF > > Patch by Justin Hibbits! > > > Two changes needed for being able to link lldb 3.5.x against llvm 3.5.x: > > http://llvm.org/viewvc/llvm-project?rev=215352&view=rev > > AArch64: add support for dynamic-loader relocations > > LLD needs them, and it's good to be able to print them properly when > our object dumpers encounter them. > > Patch by Daniel Stewart. > > http://llvm.org/viewvc/llvm-project?rev=216571&view=rev > > Fix some semantic usability issues with DynamicLibrary. > > This patch allows invalid DynamicLibrary instances to be > constructed, and fixes the const-correctness of the isValid() > method. > > > Fixing a possible SIGILL problem on ARMv6 and lower, plus test: > > http://llvm.org/viewvc/llvm-project?rev=216989&view=rev > > Only emit movw on ARMv6T2+ > > Fix PR18364. > > Patch by Dimitry Andric. > > http://llvm.org/viewvc/llvm-project?rev=216990&view=rev > > Missing test from r216989 > > > Fix assigning garbage to floats in some cases: > > http://llvm.org/viewvc/llvm-project?rev=217410&view=rev > > Set trunc store action to Expand for all X86 targets. > > When compiling without SSE2, isTruncStoreLegal(F64, F32) would return Legal, whereas with SSE2 it would return Expand. And since the Target doesn't seem to actually handle a truncstore for double -> float, it would just output a store of a full double in the space for a float hence overwriting other bits on the stack. > > Patch by Luqman Aden! > > > Enabling armv6k for FreeBSD/ARM: > > http://llvm.org/viewvc/llvm-project?rev=217454&view=rev > > Use armv6k default for FreeBSD/ARM > > Patch by Andrew Turner. > > > Downgrading a DWARF2 section error when .note sections are added to a .S file while debug info is on: > > http://llvm.org/viewvc/llvm-project?rev=218241&view=rev > > Downgrade DWARF2 section limit error to a warning > > We currently emit an error when trying to assemble a file with more > than one section using DWARF2 debug info. This should be a warning > instead, as the resulting file will still be usable, but with a > degraded debug illusion. > > > Fixing a very bad OOM condition when compiling certain programs with debug info on, plus test: > > http://llvm.org/viewvc/llvm-project?rev=221709&view=rev > > Totally forget deallocated SDNodes in SDDbgInfo. > > What would happen before that commit is that the SDDbgValues associated with > a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep > a map entry keyed by the SDNode pointer pointing to this list of invalidated > SDDbgNodes. As the memory gets reused, the list might get wrongly associated > with another new SDNode. As the SDDbgValues are cloned when they are transfered, > this can lead to an exponential number of SDDbgValues being produced during > DAGCombine like in http://llvm.org/bugs/show_bug.cgi?id=20893 > > Note that the previous behavior wasn't really buggy as the invalidation made > sure that the SDDbgValues won't be used. This commit can be considered a > memory optimization and as such is really hard to validate in a unit-test. > > http://llvm.org/viewvc/llvm-project?rev=221854&view=rev > > Add an assert and a test that verify r221709's fix. > > > Enable AArch64 support for FreeBSD: > > http://llvm.org/viewvc/llvm-project?rev=221900&view=rev > > Hook up FreeBSD AArch64 support > > Patch from Andrew Turner. > > > Partially fix FreeBSD boot2 size optimization regressions: > > http://llvm.org/viewvc/llvm-project?rev=222562&view=rev > > Disable header duplication at -Oz in loop-rotate pass. > > > -Dimitry >
On Thu, Nov 27, 2014 at 03:38:49PM +0000, Daniel Sanders wrote:> > > > I've successfully run the simple vararg test (passing 10 int's in varargs, > > > passing them in a va_list, then printing each one) for all ABI's/endians and > > > mixtures of GCC/Clang. > > > > > > > > I've also run the first 5,000 ABITestGen.py generated tests for all > > > ABI's/Endians. Big-endian O32 shows a single failure involving small > > structures > > > (this is not a regression). Big-endian N32 shows about a dozen failures that > > > do not fail on the trunk but aren't regressions either. All other ABI's and > > > Endians are passing successfully. Even with those big-endian N32 failures > > > (which fail without the patches too), this status is a big improvement on the > > > status without the patches so I'm inclined to think we should merge and fix > > > the remaining issues in 3.5.2 (assuming we do one). > > > > Tom: Is that ok with you? > > > > David: Are you using big-endian N32 or N64? > > > > > > > > I'm running an event with some students for most of today. I'll check my > > > emails when I can and I'll have my laptop but I probably won't be able to > > > merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests > > > running in the meantime. > > > > > > I will try to look at the patches today. I'm going to delay the release a week > > > or so, because of all the merge requests I've received, so there is no rush. > > > > That's a relief :-). I'll see if I can fix the N32 issues that remain on this branch. > > > > So far, I've run the first 90,000 tests for each ABI/endian with only the failures > > explained above. > > Just a quick update. The big-endian N32 failures have turned out to be false-positives. According to the logs, a shell script was briefly unavailable when it tried to run these tests. I've re-run them and they pass now. The only failure I know of is the single big-endian O32 failure.Hi Daniel, I think these look OK to merge, I just have a few requests: 1. Can you remove the git-svn-id tags from the commit messages. 2. Can you add: Merging r123456: To the first line of the commit messages so we have a record of which commit it came from. Thanks, Tom