Support different target features

[dylanmckay]

Currently LLVM makes use of the entire set of AVR instructions. This is obviously not going to work on all devices. We must add support for different variants of AVR which support different instructions.

[dylanmckay]

@4ntoine once this is implemented, support should be added to clang which gives control over what features are enabled using the command line.

[4ntoine]

I'm not sure what "devices" are meant. If it relates to MCUs, so please support these ones first:

• ATmega328
• ATmega2560
• ATmega168
• ATmega32u4

I will be able to test with them (as i'm having them)

[4ntoine]

Sure, please create new issue for support if necessary at https://github.com/4ntoine/clang/tree/avr-support

[dylanmckay]

Well, for example, the FMUL instruction is supported on some AVR MCUs but not on others. Currently we don't check for supported features and so we will emit an FMUL, which if then executed by an AVR which doesn't support it - it'll choke.

Support needs to be added to avr-llvm which notes which specific features are supported for the AVR we're compiling for, and then uses these extra functions or performs say, a software FMUL (multiply by fraction).

[4ntoine]

I'm not sure what's avr-clang and what's avr-llvm part of responsibility. I thought Clang is meant to produce arch-independent and CPU-independent LLVM bitcode (.ll) and it just passes MCU (or CPU in terms of LLVM)-specific features to be used later. And LLVM is responsible to convert that bitcode to MCU-specific instructions if supported.

So i don't understand what should be done in Clang to support MCU-specific features..
Feel free to correct me and explain the things.

BTW. LLVM/Clang supports -mcpu argument, can we use that approach (to describe mcu features easily with LLVM entities) like it's done in GCC -mmcu ?

[dylanmckay]

Yes, clang produces IR and tells LLVM what feaures (or CPU) to compile for. What I meant was that we need to add the relevant command line switches to clang so that we can actually pass -mcpu=atmega328p etc.

[4ntoine]

What's the purpose to pass -mcpu to clang? Isn't it llc from LLVM who should take -mcpu argument and use it? Or you mean Clang Driver should take -mcpu argument and pass it to tools used behind the scene like llc later?

[dylanmckay]

The second one - The clang driver should take -mcpu and pass it on to LLVM, so that if we are generating assembly or object files directly from clang, we get code which works for our processor.

I'm not sure how clang passes this information normally. I'm not sure if clang simply passes the CPU name to LLVM, then LLVM must have a list of AVR CPUs and what instructions they support, or if clang stores these lists itself, and then tells LLVM the specific features to enable. This needs to be investigated.

[4ntoine]

Ok, understood and agree.

Clang Compiler is "clang -cc1" and it does not need -mcpu argument.
Clang Driver is "clang ... -mcpu=atmega168" and it runs Clang Compiler and other tools to get the job done.

You can see how clang driver is working with "-v":

MBA-Anton:bin asmirnov$ ./clang -c /tmp/avr/Test1.c -I/Applications/avr.app/Contents/Resources/Java/hardware/tools/avr/avr/include -S -o /tmp/avr/Test1_1 -D__AVR_ATmega168__ --target=avr -mcpu=atmega168 -v
clang version 3.6.0 (https://github.com/4ntoine/clang.git b06c0492243478937f8ae13f07eda3da94e712db) (https://github.com/dylanmckay/llvm.git 1aea34ae240696b0c6f2903601a4a14da1244e1d)
Target: avr
Thread model: posix
clang: warning: argument unused during compilation: '-mcpu=atmega168'
 "/Users/asmirnov/Documents/dev/src/llvm_dylan/installed/bin/clang" -cc1 -triple avr -S -disable-free -main-file-name Test1.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases -target-linker-version 241.9 -v -dwarf-column-info -coverage-file /tmp/avr/Test1_1 -resource-dir /Users/asmirnov/Documents/dev/src/llvm_dylan/installed/bin/../lib/clang/3.6.0 -D __AVR_ATmega168__ -I /Applications/avr.app/Contents/Resources/Java/hardware/tools/avr/avr/include -fno-dwarf-directory-asm -fdebug-compilation-dir /Users/asmirnov/Documents/dev/src/llvm_dylan/installed/bin -ferror-limit 19 -fmessage-length 100 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/avr/Test1_1 -x c /tmp/avr/Test1.c
clang -cc1 version 3.6.0 based upon LLVM 3.6.0svn default target x86_64-apple-darwin13.3.0
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/avr.app/Contents/Resources/Java/hardware/tools/avr/avr/include
 /usr/local/include
 /Users/asmirnov/Documents/dev/src/llvm_dylan/installed/bin/../lib/clang/3.6.0/include
End of search list.
fatal error: error in backend: regalloc=... not currently supported with -O0
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 3.6.0 (https://github.com/4ntoine/clang.git b06c0492243478937f8ae13f07eda3da94e712db) (https://github.com/dylanmckay/llvm.git 1aea34ae240696b0c6f2903601a4a14da1244e1d)
Target: avr
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

Note Clang Driver launched Clang Compiler behind the scene.

[4ntoine]

Also note error: fatal error: error in backend: regalloc=... not currently supported with -O0. Does it relate to backend really?

[dylanmckay]

Ah, I think I know how it works. LLVM stores a list of features. LLVM also stores a list of CPUs, and the features the support.

Running llc -mcpu=help on the (non AVR) x86 LLVM gives me this impression (llc knows nothing about AVR specifically, so it must be LLVM).

The AVR-LLVM should define a generic AVR CPU. This would be the lowest common denominator, and should be the default. It would only use instructions which all AVR devices support.

It should then also define all of the AVR CPUs (atmega328, etc). This way, it would be possible to clang -mcpu=generic (the default) or clang -mcpu=atmega328. LLVM would know of the 328 and would automatically enable its features.

It is also possible to manually pass features to LLVM (see llc -mattr=help, again, use the x86 LLVM). That way, if there is an AVR CPU which AVR-LLVM does not know about, it would be possible to pass -mcpu=generic (not mandatory as it'd be default) and the explicitly enable all of the features the CPU provides with -mattr=+fmul,+sbiw etc.

The upside of this is that it should be easy to make clang support features.

[dylanmckay]

fatal error: error in backend: regalloc=... not currently supported with -O

I had this same error when I added AVR-LLVM to the Rust compiler here.

The fix (read: hack) is to turn on optimisations.

[4ntoine]

I think you're right:

MBA-Anton:bin asmirnov$ ./llc -march=avr -mcpu=help
Available CPUs for this target:

  generic - Select the generic processor.

Available features for this target:

  asmonly - Device is assembler only.

Use +feature to enable a feature, or -feature to disable it.
For example, llc -mcpu=mycpu -mattr=+feature1,-feature2

Edit Avr.td to add mcus (CPU in LLVM terms) support:

//===----------------------------------------------------------------------===//
// AVR microcontrollers supported.
//===----------------------------------------------------------------------===//

class Device<string Name, list<SubtargetFeature> Features>
  : Processor<Name, NoItineraries, Features>;

def : Device<"generic", []>;

//:FIXME: list here all mcu models

[dylanmckay]

It seems to me that llc supports enabling and disabling specific features, but clang does not. It should be extremely easy to add, considering llc in its entirety is only several hundred lines of code long. I believe that we should get into contact with the clang developers and ask why it isn't possible. It would be rarely used, as ideally we would define all AVR CPUs already, but it could be useful.

[4ntoine]

Let's try to add some mcus to Avr.td (read my comment in features issue for
llvm) and see what happens. I think all the things will be done
automatically.
27 Ноя 2014 г. 16:32 пользователь "Dylan McKay" notifications@github.com
написал:

It seems to me that llc supports enabling and disabling specific
features, but clang does not. It should be extremely easy to add,
considering llc in its entirety is only several hundred lines of code
long. I believe that we should get into contact with the clang developers
and ask why it isn't possible. It would be rarely used, as ideally we would
define all AVR CPUs already, but it could be useful.

—
Reply to this email directly or view it on GitHub
https://github.com/dylanmckay/llvm/issues/9#issuecomment-64784820.

[4ntoine]

I've tried to edit Avr.td:

class Device<string Name, list<SubtargetFeature> Features>
  : Processor<Name, NoItineraries, Features>;

def : Device<"generic", []>;
def : Device<"atmega168", []>;

and get it:

MBA-Anton:bin asmirnov$ ./llc -march=avr -mcpu=help
Available CPUs for this target:

  atmega168 - Select the atmega168 processor.
  generic   - Select the generic processor.

Available features for this target:

  asmonly - Device is assembler only.

Use +feature to enable a feature, or -feature to disable it.
For example, llc -mcpu=mycpu -mattr=+feature1,-feature2
'help' is not a recognized processor for this target (ignoring processor)

[4ntoine]

so the features should be declared in the similar way:

//:FIXME: IMPLEMENT and list all features
def FeatureAsmOnly
  : SubtargetFeature<"asmonly","IsAsmOnly", "true",
                     "Device is assembler only">;

[4ntoine]

i think after fixing regalloc issue (just invoking with -O2 f.e.) -mcpu argument will be passed to llc by Clang Driver automatically

[4ntoine]

http://llvm.org/docs/WritingAnLLVMBackend.html#subtarget-support

[dylanmckay]

When you said you tried to edit Avr.rd, did you mean the one in the AVR-LLVM repo or is there one in clang?

[4ntoine]

llvm

[dylanmckay]

Subtarget features are now implemented