llvm dev - Jan 2019 - Should CPPFLAGS and CFLAGS still be used when compiling .ll to .o?

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.

OUTPUT_OPTION = -o $@
COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c

%.o: %.c
#  commands to execute (built-in):
  $(COMPILE.c) $(OUTPUT_OPTION) $<

My understanding is that since $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH)
already has been used for .c -> .ll conversion, .ll ->.o conversions
doesn't need $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) any more. Is it so?

So the following rule should be sufficient?

%.o: %.ll
#  commands to execute (built-in):
  $(CC) $(OUTPUT_OPTION) $<

-- 
Regards,
Peng

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.
> 
> OUTPUT_OPTION = -o $@
> COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
> 
> %.o: %.c
> #  commands to execute (built-in):
>   $(COMPILE.c) $(OUTPUT_OPTION) $<
> 
> My understanding is that since $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH)
> already has been used for .c -> .ll conversion, .ll ->.o conversions
> doesn't need $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) 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) $(OUTPUT_OPTION) $<
Beware that .ll files may be generated from something else than C code, I'd
be wary of $(CC) and maybe introduce $(LLC) and set $(LLCFLAGS) to -filetype=obj
?
That would also avoid stupid situation where a user set CC=gcc

hope it helps,

serge