Bug 214904 - head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c
Summary: head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: reject...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: powerpc Any
: --- Affects Only Me
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2016-11-28 11:49 UTC by Mark Millard
Modified: 2017-03-18 20:15 UTC (History)
1 user (show)

See Also:


Attachments
patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (866 bytes, patch)
2016-12-09 02:13 UTC, Mark Millard
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-11-28 11:49:57 UTC
[To get this far I had to WERROR= to get past other rejections
for some C/C++ sorts of issues.]

Below are some example errors that clang 3.9.0 reports for trying to
handle the assembler notations that are used:

--- hwpmc_e500.o ---
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: unrecognized instruction mnemonic
        uint32_t pmgc0 = mfpmr(PMR_PMGC0);
                         ^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
          __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg));       \
                           ^
<inline asm>:1:2: note: instantiated into assembly here
        mfpmr 3,400
        ^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: unrecognized instruction mnemonic
        mtpmr(PMR_PMGC0, pmgc0);
        ^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
        __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
                         ^
<inline asm>:1:2: note: instantiated into assembly here
        mtpmr 400,3
        ^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: unrecognized instruction mnemonic
        mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE);
        ^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
        __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
                         ^
<inline asm>:1:2: note: instantiated into assembly here
        mtpmr 400,3
        ^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: unrecognized instruction mnemonic
                pmc_pmlc = mfpmr(PMR_PMLCa0);
                           ^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
          __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg));       \
                           ^
<inline asm>:1:2: note: instantiated into assembly here
        mfpmr 10,144
        ^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:410:3: error: unrecognized instruction mnemonic
                mtpmr(PMR_PMLCa0, pmc_pmlc);
                ^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
        __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
                         ^
<inline asm>:1:2: note: instantiated into assembly here
        mtpmr 144,10
        ^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:413:14: error: unrecognized instruction mnemonic
                pmc_pmlc = mfpmr(PMR_PMLCa1);
                           ^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
          __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg));       \
                           ^
<inline asm>:1:2: note: instantiated into assembly here
        mfpmr 10,145
        ^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:415:3: error: unrecognized instruction mnemonic
                mtpmr(PMR_PMLCa1, pmc_pmlc);
                ^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
        __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
                         ^
<inline asm>:1:2: note: instantiated into assembly here
        mtpmr 145,10
        ^
Comment 1 Mark Millard 2016-12-04 05:14:44 UTC
(In reply to Mark Millard from comment #0)

I've now also tried this on a powerpc64 running a minor variant
of head -r309179 and it gets the same result that the amd64
cross build for TARGET_ARCH=powerpc64 does --unlike the
buildworld WITH_LIB32= issue now listed in bugzilla 215037.

Here it seems that the "BOOK E" specific instructions are
missing from the assembler notation that clang 3.9.0 supports
for TARGET_ARCH=powerpc64. There might be other non-classic
PowerPc instructions also missing for all I know.

I've sent a note asking Justin Hibbits what he thinks the
proper classification of this is. Does llvm need to support
the BOOK E specific instructions on the assembler notation
in order for FreeBSD to use clang as the system compiler?

Even if GENERIC64 could avoid including such things there
would still be the issue of how to allow more specialized
builds to target BOOK E (or other variants with special
instructions for the variant).

This may need a related llvm bugzilla submittal to be
listed in the:

[META] Using Clang as the FreeBSD/ppc system compiler

(25780 for llvm).
Comment 2 Mark Millard 2016-12-09 02:13:53 UTC
Created attachment 177812 [details]
patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td

Roman Divacky provided the patch and had me test it
on am old PowerMac G5 so-called "Quad Core". It
allowed hwpmc_e500.o to be built and the build to
then continue on to other things instead of
stopping.

(The svnlite diff output is mine in order to be a
comparison against a more modern version than roman
originally used --and so mine has a closer file line
number match.)
Comment 3 Mark Millard 2017-01-04 22:03:11 UTC
Comment on attachment 177812 [details]
patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td

Roman Divacky reports that this patch is incomplete, quoting:

. . . the patch is not finished and I don't
have the time nor the resources (I would need to implement the scheduling
for that instruction) to finish it.

I just did it to let you continue your exploring. . . .
Comment 4 Justin Hibbits freebsd_committer freebsd_triage 2017-03-18 20:15:30 UTC
Fixed by the import of clang 4.0.0 (changes committed upstream to llvm)