search for: rl78

Hello all, For the past couple of months I've been writing a new llvm backend for Renesas RL78 MCU: https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rl78.html The software manual which contains all there is to know about RL78 is available here: https://www.renesas.com/us/en/doc/products/mpumcu/doc/rl78/r01us0015ej0220_rl78.pdf The motivation behind this is the followi...

...things >>are being worked on, how likely they are to continue to be invested in, etc - versus accepting that companies have their own >>priorities, some private objectives, etc). No worries I’m very happy to provide any information necessary. I really want the port to accepted upstream. RL78 MCUs are part of the Renesas Product Longevity program https://www.renesas.com/eu/en/support/products-common/product-longevity-program-plp.html. The majority of current RL78 devices have the termination date set as “December 2033”, and a few “March 2026”. Also RL78 is under active development: new...

...pilers you're trying to be compatible with publicly available/documented? Yes the compiler can be downloaded from here (is available for free with some restrictions compared to the paid version). https://www.renesas.com/in/en/products/software-tools/tools/compiler-assembler/compiler-package-for-rl78-family.html The documentation is available as well (in toolchain installer and website): https://www.renesas.com/in/en/doc/products/tool/doc/015/r20ut3123ej0109-ccrl.pdf >>The other aspect to new features, targets, etc, is the ongoing support - might be relevant to know a bit more about you/...

...sting linker relaxation schemes already do similar things. Deleting a trailing jump is similar to RISC-V where sections can shrink (not implemented in lld; R_RISCV_ALIGN and R_RISCV_RELAX are in my mind)) (binutils supports deleting bytes for a few other architectures, e.g. msp430, sh, mips, ft32, rl78). With just minimal amount of disassembly work, conceptually the framework should not be too hard to be ported to another target. One thing I was not aware of (perhaps the description did not make it clear) is that Propeller intends to **reorder basic block sections across translation units**. Th...

...a function declaration. * Add the attribute to the IR Set of Attributes. 3) CodeGen * noopt implies 'noinline. * noopt always wins over always_inline * noopt does not win over 'naked': naked functions only contain asm statements. This attribute is only valid for ARM, AVX, MCORE, RL78, RX and SPU to indicate that the specified function does not need prologue/epilogue sequence generated by the compiler. (NOTE: this constraint can be removed). 4) Add clang tests: * in test/Sema: ** Verify that noopt only applies to functions. (-cc1 -fsyntax-only -verify) * in test/C...

Hello, would it be possible to update config.sub and config.guess to the latest versions (or at least version from automake-1.13.1) in order to support new architectures based on the ARM 64 bit CPU? Patch: http://plautrba.fedorapeople.org/openssh/openssh-latest-config.sub-config.guess.patch Related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=926284 Thanks, Petr

...dd the attribute to the IR Set of Attributes. > 3) CodeGen > * noopt implies 'noinline. > * noopt always wins over always_inline > * noopt does not win over 'naked': naked functions only contain asm > statements. This attribute is only valid for ARM, AVX, MCORE, RL78, RX > and > SPU to indicate that the specified function does not need > prologue/epilogue > sequence generated by the compiler. (NOTE: this constraint can be > removed). > 4) Add clang tests: > * in test/Sema: > ** Verify that noopt only applies to functions. (...

...* Add the attribute to the IR Set of Attributes. > 3) CodeGen > * noopt implies 'noinline. > * noopt always wins over always_inline > * noopt does not win over 'naked': naked functions only contain asm > statements. This attribute is only valid for ARM, AVX, MCORE, RL78, RX > and > SPU to indicate that the specified function does not need > prologue/epilogue > sequence generated by the compiler. (NOTE: this constraint can be > removed). > 4) Add clang tests: > * in test/Sema: > ** Verify that noopt only applies to functions. (-cc1...

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and