Add Features flag for LLVM CPU optimizations

[j7b]

Allows specifying llvm machine features (otherwise specified with -mattr elsewhere in llvm toolchains) via "features" key in targets JSON configuration. Intended to work around issues with AVR object gen, which appear unresolved (identified at avr-llvm/llvm#216 and elsewhere) but should eventually be resolved and adds potentially useful options for stable targets.

[aykevl]

Does this fix the problem in AVR? Did you test it?
Nothing against this PR - I think it is useful - but I doubt it helps the AVR backend.

[deadprogram]

Yes @j7b can you please provide an example of this in use for testing? Thank you.

[j7b]

Tinygo emits warnings for invalid features as expected, indicating the bindings work as advertised; it appears the issue for avr targets at llvm 7.0 is high-level optimizations assume the 16-bit ops are valid, it appears the productions that trigger them would be inefficient to the point of general impracticality otherwise.

[aykevl]

it appears the issue for avr targets at llvm 7.0 is high-level optimizations assume the 16-bit ops are valid

As far as I know, LLVM wasn't designed with systems in mind where general purpose registers are smaller than pointers, as is the case on AVR (8 bit general purpose registers, 16 bit pointers on most chips). The way that they work around it is by emitting 16-bit pseudo instructions that are later lowered to the actual 8 bits instructions.
This probably doesn't produce very efficient code but changing LLVM in this regard would be a lot of work.

Not sure how this relates to CPU features, though.

[j7b]

I think the scope of evaluation for this changeset should be limited to feature specification in targets, as an analog to invocations of llvm toolchain utilities using -mattr, the binding is demonstrated to work as invalid features input produces warnings, the inaccurate featuresets specified for a number of atmel parts and astonishing behavior of the optimizer are in the hands of the llvm project.

[deadprogram]

@j7b can you please provide an example of use so I can test more completely?

Also, this flag needs to be documented somewhere. How about adding to https://github.com/tinygo-org/tinygo-site/blob/master/content/usage/misc-options.md

Thanks!

[j7b]

A brutal test is to make a copy of digispark.json with "features":["-sram"], property added, try to compile blinky1 (or anything with a constant that's not optimized away), compilation will fail when llvm tries to assign the instructions to copy constants to sram.

Where'd "adding a target" go in the docs? That was the only thing I recollect that sort of documented the target jsons.

[aykevl]

The original bug that led to this PR is now being worked on: avr-rust/rust-legacy-fork#124

Where'd "adding a target" go in the docs? That was the only thing I recollect that sort of documented the target jsons.

https://github.com/aykevl/tinygo/wiki/Adding-a-new-board

[aykevl]

I have rebased and merged this in 0ae467d. It is very useful for RISC-V support.