Add suffix rules for LLVM IR and bitcode.
ClosedPublic

Authored by jonathan on Dec 1 2015, 10:44 PM.

Details

Summary

As a foundation for doing more exciting things with LLVM IR (Intermediate
Representation), add suffix rules to generate IR from C or C++ files.
The definition of these rules is conditional on COMPILER_TYPE=="clang",
since the -emit-llvm flag doesn't mean much to gcc.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
jonathan retitled this revision from to Add suffix rules for LLVM IR and bitcode..Dec 1 2015, 10:44 PM
jonathan updated this object.
jonathan edited the test plan for this revision. (Show Details)
jonathan added reviewers: brooks, rwatson, theraven.
bdrewery added inline comments.Dec 1 2015, 11:47 PM
share/mk/sys.mk
109 ↗(On Diff #10651)

COMPILER_TYPE won't work in this file. sys.mk is loaded before Makefile is. We've tried to include bsd.compiler.mk this early but ran into problems.

If the build rules depend on having clang as a compiler, what happens if you use GCC? It just says "don't know how to build foo.c.bco"?

emaste added inline comments.Dec 1 2015, 11:49 PM
share/mk/bsd.lib.mk
64–65 ↗(On Diff #10651)

Is this convention established elsewhere too?

imp added inline comments.Dec 1 2015, 11:58 PM
share/mk/sys.mk
109 ↗(On Diff #10651)

We're moving things out of sys.mk. bsd.compiler.mk was one thing. bsd.cpu.mk is also on the way out too.
I hate to sound like bde here, but why do these need to be global to everything? There's no %POSIX protection
though I haven't checked to see if it's part of a bigger posix section.

135 ↗(On Diff #10651)

Why does this need to be global?

303–326 ↗(On Diff #10651)

These would be better in bsd.init.mk or something similar. You can't test COMPILER_TYPE here.

Alternatively, make them unconditional. If the compiler doesn't understand things, it will just
fail. It will fail without the tests anyway.

bdrewery added inline comments.Dec 2 2015, 12:02 AM
share/mk/sys.mk
109 ↗(On Diff #10651)

I really want to merge the suffix transformation rules, perhaps into bsd.suffix.mk, and include from bsd.obj.mk.

Thanks, all, for the comments! It sounds like there might be some rationalization of suffix rules in the works? If so, perhaps I should hold off so that we only have to add a single set of rules rather than adding the same thing twice in bsd.lib.mk and sys.mk...

share/mk/bsd.lib.mk
64–65 ↗(On Diff #10651)

Referring to the suffix or the comment? If the suffix, I was attempting to match the .po and .So convention, i.e., "special kind of .o file". If the comment, I was attempting to match the following line that describes the .So file.

share/mk/sys.mk
109 ↗(On Diff #10651)

Moving things into bsd.suffix.mk sounds great: I was a bit perturbed by the need to modify .SUFFIXES in two files. Does this mean that I should hold off with this patch until other changes settle out?

303–326 ↗(On Diff #10651)

I'd be happy to make these things unconditional, but it sounds like things are moving around in the meantime?

brooks added inline comments.Dec 3 2015, 9:45 AM
share/mk/bsd.lib.mk
64–65 ↗(On Diff #10651)

I don't know of any specific standard extensions and they wouldn't really work anyway because IR is combined multiple times before it is used. In this case we're making it us as we go along.

The overall problem (not apparent in this patch because its just part of a larger picture) is that we need to specify multiple different ways to get from a collection of C files to a program. For example, some paths might look like *.c->*.llo->*.o->${PROG} while others might be *.c->*.llo->*.lla->${PROG}. Make isn't good to letting you control which path you take to get from *.c to ${PROG} so a fair bit of ugly extension hacker is required to produce a flexible system.

jonathan updated this revision to Diff 21285.Oct 12 2016, 1:22 AM

Rework this change based on rS307075 (suffix rule files).

Referring to the suffix or the comment?

Was referring to the suffix, and mainly just curious.

share/mk/bsd.suffixes.mk
35 ↗(On Diff #21285)

Aside, are we aware of any actual use of .C for C++ files?

jonathan marked 7 inline comments as done.Oct 19 2016, 11:51 PM

This is a much simpler change after rS307075. How does it look to everyone now?

share/mk/bsd.suffixes.mk
35 ↗(On Diff #21285)

Nope, I've never seen .C in the wild. One "source" claims that Stroustrup used to use .C, which seems to jive with the implication of his style guide, but I suspect that .C has been uncommon since Windows 3.1 started getting popular. :)

In fact, Stroustrup now recommends .cpp though the CppCoreGuidelines project.

share/mk/sys.mk
135 ↗(On Diff #10651)

I suppose they don't necessarily need to be global. I was just trying to mimic the structure of PO_CXXFLAGS: defined in sys.mk and used in bsd.lib.mk (and, in the case of IR, bsd.prog.mk).

imp added a comment.Oct 20 2016, 3:26 AM

Other than historical trivial, this looks good to me.

share/mk/bsd.suffixes.mk
35 ↗(On Diff #21285)

I've personally worked on three different projects that used .C for C++ files. One from 1990-1993, one from 1995-1996, and one in 1998. The deja-gnu test suite for C++ (as recently as 4.6) and there's about 100 patch files in ports for files ending in .C.

rwatson accepted this revision.Oct 20 2016, 1:55 PM

Mentor approval granted. (NB: not a technical review, but existing technical reviews here look good to go!)

This revision is now accepted and ready to land.Oct 20 2016, 1:55 PM
This revision was automatically updated to reflect the committed changes.
jonathan marked an inline comment as done.