llvm dev - Jul 2015 - [LLVMdev] [3.7.0] Two late issues with cross compilation to mips

Hi,

Sorry for the late report but I've only just found these issues. Llvm.org
isn't working for me at the moment but I'll file tickets once it is.

The issues are:

1.       Almabench has some significant numerical differences and fails the
reference check for some configs. I'm investigating this one at the moment
but early indications are that it's a similar (but different) problem to the
one we had in LLVM 3.6.2.

2.       Read-only exception tables have broken compatibility with the ~2 year
old gcc toolchains I was using for release testing cross compilation. This
isn't a problem for most test-suite runs since we can just update the
assembler but is causing trouble for microMIPS. More recent toolchains lack the
microMIPS multilib I was using and migrating to the new one is causing link
failures. These failures are related to ELF header bits specifying the SNaN/QNaN
encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the -mnan=2008
isn't reaching the assembler.

3.       Clang is incompatible with changes to the mips-mti-linux-gnu sysroot
from Imagination's mips-mti-linux-gnu toolchain. Libaries are still
multilib'd (albeit with a reduced set) but some of the include paths
aren't anymore. It's also no longer correct to include sysroot/include
(this path is added by common code) since this skips some function definitions.
Instead, we must only include sysroot/usr/include like GCC does. There may be
more details but so far the fix doesn't look simple. As far as I can tell,
clang's multilib expects includes and libraries to have the same layout
(osSuffix() seems to control both). The good news is that it's not a
regression since we can use toolchains from before this layout change.

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<http://www.imgtec.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/f303b0d5/attachment.html>

#2 has turned out to be user error combined with inconsistent leniency in the
driver. -mnan=2008 strictly conforms to the documentation and is passed on for
MIPS32R3 and ignored for MIPS32R2 (which didn't have IEEE754-2008 support).
However, -mmicromips is (currently) permitted for MIPS32R2 even though it too
was added in MIPS32R3. I've corrected my test configuration and I'll
tighten this up in later releases.

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Daniel Sanders
Sent: 29 July 2015 11:08
To: Hans Wennborg (hans at chromium.org)
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: [LLVMdev] [3.7.0] Two late issues with cross compilation to mips

Hi,

Sorry for the late report but I've only just found these issues. Llvm.org
isn't working for me at the moment but I'll file tickets once it is.

The issues are:

1.       Almabench has some significant numerical differences and fails the
reference check for some configs. I'm investigating this one at the moment
but early indications are that it's a similar (but different) problem to the
one we had in LLVM 3.6.2.

2.       Read-only exception tables have broken compatibility with the ~2 year
old gcc toolchains I was using for release testing cross compilation. This
isn't a problem for most test-suite runs since we can just update the
assembler but is causing trouble for microMIPS. More recent toolchains lack the
microMIPS multilib I was using and migrating to the new one is causing link
failures. These failures are related to ELF header bits specifying the SNaN/QNaN
encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the -mnan=2008
isn't reaching the assembler.

3.       Clang is incompatible with changes to the mips-mti-linux-gnu sysroot
from Imagination's mips-mti-linux-gnu toolchain. Libaries are still
multilib'd (albeit with a reduced set) but some of the include paths
aren't anymore. It's also no longer correct to include sysroot/include
(this path is added by common code) since this skips some function definitions.
Instead, we must only include sysroot/usr/include like GCC does. There may be
more details but so far the fix doesn't look simple. As far as I can tell,
clang's multilib expects includes and libraries to have the same layout
(osSuffix() seems to control both). The good news is that it's not a
regression since we can use toolchains from before this layout change.

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.imgtec.com_&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=K4CUih-MV4ytxP4HxETs-aexQWt_VhGzdtvS7Q4PtfE&s=jNuftM3MAhxKCT54sfMJDt_51K15C6aqrspFaUvRUB8&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/74f74dab/attachment.html>

Hi Daniel,

I am on a vacation now till the Aug 3 but I can take a look at these
problems. What is the most important?

As to the issue #3 - do we need to keep compatibility with the old
mips-mti-linux-gnu toolchain layout?

Simon

On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
> The issues are:
>
> 1.       Almabench has some significant numerical differences and fails the
> reference check for some configs. I'm investigating this one at the
moment
> but early indications are that it's a similar (but different) problem
to the
> one we had in LLVM 3.6.2.
>
> 2.       Read-only exception tables have broken compatibility with the ~2
> year old gcc toolchains I was using for release testing cross compilation.
> This isn't a problem for most test-suite runs since we can just update
the
> assembler but is causing trouble for microMIPS. More recent toolchains lack
> the microMIPS multilib I was using and migrating to the new one is causing
> link failures. These failures are related to ELF header bits specifying the
> SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect
> the –mnan=2008 isn't reaching the assembler.
>
> 3.       Clang is incompatible with changes to the mips-mti-linux-gnu
> sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are
still
> multilib'd (albeit with a reduced set) but some of the include paths
aren't
> anymore. It's also no longer correct to include sysroot/include (this
path
> is added by common code) since this skips some function definitions.
> Instead, we must only include sysroot/usr/include like GCC does. There may
> be more details but so far the fix doesn't look simple. As far as I can
> tell, clang's multilib expects includes and libraries to have the same
> layout (osSuffix() seems to control both). The good news is that it's
not a
> regression since we can use toolchains from before this layout change.

#1 is the most important but I'm already debugging that. I don't want to
interrupt your holiday but if you could look at #3 that would be great.
> As to the issue #3 - do we need to keep compatibility with the old
mips-mti-linux-gnu toolchain layout?
It would be nice to support both the old and new layouts but I doubt that's
possible with the current framework (see below). If it's not possible then
we should use the new layout and encourage users to update their gcc toolchains
since the new layout has been in use for at least 6 months.

I believe that supporting both layouts ties into the later target triple work to
some degree. There are at least three mips-mti-linux-gnu toolchains with
different sets of multilibs, and anyone can build more variants of the
mips-mti-linux-gnu toolchain. So ideally, we should be able to configure the
multilib layout at configure-time or using config files. Of course, implementing
this kind of thing is too much work for this release.
> -----Original Message-----
> From: Simon Atanasyan [mailto:simon at atanasyan.com]
> Sent: 29 July 2015 13:04
> To: Daniel Sanders
> Cc: Hans Wennborg (hans at chromium.org); LLVM Developers Mailing List
> (llvmdev at cs.uiuc.edu)
> Subject: Re: [3.7.0] Two late issues with cross compilation to mips
> 
> Hi Daniel,
> 
> I am on a vacation now till the Aug 3 but I can take a look at these
> problems. What is the most important?
> 
> As to the issue #3 - do we need to keep compatibility with the old
> mips-mti-linux-gnu toolchain layout?
> 
> Simon
> 
> On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders
> <Daniel.Sanders at imgtec.com> wrote:
> > The issues are:
> >
> > 1.       Almabench has some significant numerical differences and
fails the
> > reference check for some configs. I'm investigating this one at
the moment
> > but early indications are that it's a similar (but different)
problem to the
> > one we had in LLVM 3.6.2.
> >
> > 2.       Read-only exception tables have broken compatibility with the
~2
> > year old gcc toolchains I was using for release testing cross
compilation.
> > This isn't a problem for most test-suite runs since we can just
update the
> > assembler but is causing trouble for microMIPS. More recent toolchains
> lack
> > the microMIPS multilib I was using and migrating to the new one is
causing
> > link failures. These failures are related to ELF header bits
specifying the
> > SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I
> suspect
> > the –mnan=2008 isn't reaching the assembler.
> >
> > 3.       Clang is incompatible with changes to the mips-mti-linux-gnu
> > sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries
are still
> > multilib'd (albeit with a reduced set) but some of the include
paths aren't
> > anymore. It's also no longer correct to include sysroot/include
(this path
> > is added by common code) since this skips some function definitions.
> > Instead, we must only include sysroot/usr/include like GCC does. There
> may
> > be more details but so far the fix doesn't look simple. As far as
I can
> > tell, clang's multilib expects includes and libraries to have the
same
> > layout (osSuffix() seems to control both). The good news is that
it's not a
> > regression since we can use toolchains from before this layout change.

I believe I've identified the problem with almabench but I haven't found
the root cause in the compiler yet.

The problem is that a caller saved register ($f14) is being moved across a call
and this call sometimes clobbers the value. As a result, the value of the TWOPI
constant used in the fmod() calls isn't always 2*PI.

According to -print-after-all, the pass that moves the instruction is Simple
Register Coalescing. The bit I'm stuck on at the moment is that I'm not
sure what information is supposed to prevent this move from happening. I thought
there was supposed to be an ImplicitDefine on the call instruction for each
clobbered register but this doesn't seem to be the case. Am I missing
something obvious?
________________________________________
From: Daniel Sanders
Sent: 29 July 2015 11:08
To: Hans Wennborg (hans at chromium.org)
Cc: Simon Atanasyan (simon at atanasyan.com); LLVM Developers Mailing List
(llvmdev at cs.uiuc.edu)
Subject: [3.7.0] Two late issues with cross compilation to mips

Hi,

Sorry for the late report but I've only just found these issues. Llvm.org
isn't working for me at the moment but I'll file tickets once it is.

The issues are:

1.       Almabench has some significant numerical differences and fails the
reference check for some configs. I'm investigating this one at the moment
but early indications are that it's a similar (but different) problem to the
one we had in LLVM 3.6.2.

2.       Read-only exception tables have broken compatibility with the ~2 year
old gcc toolchains I was using for release testing cross compilation. This
isn't a problem for most test-suite runs since we can just update the
assembler but is causing trouble for microMIPS. More recent toolchains lack the
microMIPS multilib I was using and migrating to the new one is causing link
failures. These failures are related to ELF header bits specifying the SNaN/QNaN
encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the –mnan=2008
isn't reaching the assembler.

3.       Clang is incompatible with changes to the mips-mti-linux-gnu sysroot
from Imagination's mips-mti-linux-gnu toolchain. Libaries are still
multilib'd (albeit with a reduced set) but some of the include paths
aren't anymore. It's also no longer correct to include sysroot/include
(this path is added by common code) since this skips some function definitions.
Instead, we must only include sysroot/usr/include like GCC does. There may be
more details but so far the fix doesn't look simple. As far as I can tell,
clang's multilib expects includes and libraries to have the same layout
(osSuffix() seems to control both). The good news is that it's not a
regression since we can use toolchains from before this layout change.

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<http://www.imgtec.com/>

To reduce memory consumption clobbered registers are handled with RegisterMask
machine operands which contain a bitset of all registers clobbered.

- Matthias
> On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at
imgtec.com> wrote:
> 
> I believe I've identified the problem with almabench but I haven't
found the root cause in the compiler yet.
> 
> The problem is that a caller saved register ($f14) is being moved across a
call and this call sometimes clobbers the value. As a result, the value of the
TWOPI constant used in the fmod() calls isn't always 2*PI.
> 
> According to -print-after-all, the pass that moves the instruction is
Simple Register Coalescing. The bit I'm stuck on at the moment is that
I'm not sure what information is supposed to prevent this move from
happening. I thought there was supposed to be an ImplicitDefine on the call
instruction for each clobbered register but this doesn't seem to be the
case. Am I missing something obvious?
> ________________________________________
> From: Daniel Sanders
> Sent: 29 July 2015 11:08
> To: Hans Wennborg (hans at chromium.org <mailto:hans at
chromium.org>)
> Cc: Simon Atanasyan (simon at atanasyan.com <mailto:simon at
atanasyan.com>); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu
<mailto:llvmdev at cs.uiuc.edu>)
> Subject: [3.7.0] Two late issues with cross compilation to mips
> 
> Hi,
> 
> Sorry for the late report but I've only just found these issues.
Llvm.org isn't working for me at the moment but I'll file tickets once
it is.
> 
> The issues are:
> 
> 1.       Almabench has some significant numerical differences and fails the
reference check for some configs. I'm investigating this one at the moment
but early indications are that it's a similar (but different) problem to the
one we had in LLVM 3.6.2.
> 
> 2.       Read-only exception tables have broken compatibility with the ~2
year old gcc toolchains I was using for release testing cross compilation. This
isn't a problem for most test-suite runs since we can just update the
assembler but is causing trouble for microMIPS. More recent toolchains lack the
microMIPS multilib I was using and migrating to the new one is causing link
failures. These failures are related to ELF header bits specifying the SNaN/QNaN
encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the –mnan=2008
isn't reaching the assembler.
> 
> 3.       Clang is incompatible with changes to the mips-mti-linux-gnu
sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are still
multilib'd (albeit with a reduced set) but some of the include paths
aren't anymore. It's also no longer correct to include sysroot/include
(this path is added by common code) since this skips some function definitions.
Instead, we must only include sysroot/usr/include like GCC does. There may be
more details but so far the fix doesn't look simple. As far as I can tell,
clang's multilib expects includes and libraries to have the same layout
(osSuffix() seems to control both). The good news is that it's not a
regression since we can use toolchains from before this layout change.
> 
> Daniel Sanders
> Leading Software Design Engineer, MIPS Processor IP
> Imagination Technologies Limited
> www.imgtec.com <http://www.imgtec.com/><http://www.imgtec.com/
<http://www.imgtec.com/>>
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/b2ffc141/attachment.html>