[llvm-dev] Should CPPFLAGS and CFLAGS still be used when compiling .ll to .o? (original) (raw)
Serge Guelton via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 25 02:35:29 PST 2019
- Previous message: [llvm-dev] Should CPPFLAGS and CFLAGS still be used when compiling .ll to .o?
- Next message: [llvm-dev] [System Model] MC layer vs. Target layer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Jan 24, 2019 at 12:23:01PM -0600, Peng Yu via llvm-dev wrote:
I am trying to use GNU make generating .o from .ll (which is converted from .c)
GNU use the following variable and rule to generate .o from .c. I'd like to follow its convention. OUTPUTOPTION = -o $@ COMPILE.c = (CC)(CC) (CC)(CFLAGS) (CPPFLAGS)(CPPFLAGS) (CPPFLAGS)(TARGETARCH) -c %.o: %.c # commands to execute (built-in): $(COMPILE.c) (OUTPUTOPTION)(OUTPUTOPTION) (OUTPUTOPTION)<_ _My understanding is that since (CFLAGS)(CFLAGS) (CFLAGS)(CPPFLAGS) $(TARGETARCH) already has been used for .c -> .ll conversion, .ll ->.o conversions doesn't need (CFLAGS)(CFLAGS) (CFLAGS)(CPPFLAGS) $(TARGETARCH) any more. Is it so?
That's my feeling too. Moreover,
- as .ll files already embed machine-specific information, it could lead to invalid code
- if the .ll file was generated with -O0, it will carry optnone attribute and won't be sensible to extra optimisations anyway
So the following rule should be sufficient?
%.o: %.ll # commands to execute (built-in): $(CC) (OUTPUTOPTION)(OUTPUTOPTION) (OUTPUTOPTION)<
Beware that .ll files may be generated from something else than C code, I'd be wary of (CC)andmaybeintroduce(CC) and maybe introduce (CC)andmaybeintroduce(LLC) and set $(LLCFLAGS) to -filetype=obj ? That would also avoid stupid situation where a user set CC=gcc
hope it helps,
serge
- Previous message: [llvm-dev] Should CPPFLAGS and CFLAGS still be used when compiling .ll to .o?
- Next message: [llvm-dev] [System Model] MC layer vs. Target layer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]