Readme for C29 Clang Code Generation Tools 2.0.0.STS
Table of Contents
Introduction
Version 2.0.0.STS of the C29 Clang Compiler Tools, also known as the c29clang compiler, is derived from the open source LLVM/Clang source code base and the LLVM Compiler Infrastructure source base that can be found in GitHub (github.com).
The c29clang compiler can be used to compile and link C/C++ and assembly source files to build static executable application files that can be loaded and run on a C29 processor.
Short-Term Support Release
This is a Short-Term Support (STS) release.
For definitions and explanations of STS, LTS, and the versioning number scheme, please see SDTO Compiler Version Numbers.
Documentation
The C29 Clang Compiler Tools User’s Guide is now available online at the following URL:
TI E2E Community - Where to Get Help
Post compiler related questions to the TI E2E design community forum and select the TI device being used.
The following is the top-level webpage for all of TI’s Code Generation Tools.
If submitting a defect report, please attach a scaled-down test case with command-line options and the compiler version number to allow us to reproduce the issue easily.
Defect Tracking Database
Compiler defect reports can be tracked at the new Development Tools bug database, SIR. SIR is a JIRA-based view into all public tools defects.
A my.ti.com account is required to access this page. To find an issue in SIR, enter your defect id in the top right search box once logged in. Alternatively, from the top red navigation bar, select “Issues” then “Search for Issues”.
New Features Added in the 2.0.0.STS Release
Link-time Optimization (-flto)
The c29clang compiler toolchain now supports the powerful link-time optimization strategy. When ‘-flto’ is passed as an option to a link command, the linker identifies other object files (including those in libraries) that were compiled with ‘-flto’ and generates a single, combined code module. The compiler uses this new knowledge to further optimize the final program. For example, consider two source files:
// file1.c
extern int return_value();
int add_value(int x) { return x + return_value(); }
// file2.c
With c29clang file1.c file2.c -O3
, the compiler can’t see the definition of ‘return_value’ in ‘file2.c’ while optimizing ‘file1.c’, leading the generated code for add_value to contain a non-performant CALL sequence.
With c29clang file1.c file2.c -flto -O3
, the compiler acts the same as before until the linker executes. The tool will extract representations of code from file1.c and file2.c and generate a new translation unit that looks similar to:
// files.c
extern int return_value();
int add_value(int x) { return x + return_value(); }
int return_value() { return 5; }
This is optimized once more. Now that the compiler can see the definition of return_value, it can replace the call to it in add_value with the literal 5, removing the CALL sequence entirely.
All objects must be built with -flto to be included in optimization strategy. In particular, it’s important that libraries built or imported into your project have been built with -flto. Objects not built with -flto will not be added to the combined module.
Link-time optimization interacts in complex ways with hardware security configurations because it involves the movement of code and data accesses across what may be a secure boundary containing protected calls and returns. This means that the presence of security in a link-time optimized project may degrade performance over that same project with no security.
Hardware Security (C28 SSU)
The 1.0.0.LTS contained security guides in linker command files, using the SECURE_GROUP syntax. In 2.0.0.STS and forward, there have been changes to this syntax.
- SECURE_GROUP should only be applied to MEMORY ranges, and will apply to all output SECTIONS that may be placed into it
- SECURE_GROUP is still valid on output SECTIONS, but is deprecated and may be removed at a future date
- SECURE_GROUPs require a name, the ‘call group’
- Two SECURE_GROUPs with the same name can freely contain calls into one another
- A SECURE_GROUP may optionally specify either the PUBLIC or PRIVATE attribute
- PRIVATE is the default specification if nothing is specified
- If the SECURE_GROUP of a callee is PRIVATE and has a different call group than the caller, the linker generates an error
- If the SECURE_GROUP of a callee is PUBLIC and has a different call group than the caller, the linker generates blocks of code, called trampolines and landing pads, which implement the missing protect CALL and RET sequences
- SECURE_GROUPs can optionally declare lists of resources that code contained in that group can/will read from or write to
- This is done with the READS and WRITES SECURE_GROUP attributes
- Resource names may be any informative string, but generally are identified as MEMORY ranges that will contain the data being accessed
- Two code sections are compatible if every placement option of the caller has access to resources accessed by the callee in any placement configuration, making them amenable to inter-procedural optimization during link-time optimization
Note: These hardware security guides have no effect on the hardware configuration and serve only as extra information for the linker. The CPU must be set up for security manually or with the SysCfg tool, which additionally generates these guides for you.
Example:
MEMORY {
FLASH (X): origin=0x20 length=0x1000
SECURE_GROUP(FLASH_GROUP, PUBLIC, READS=(R1, R2), WRITES=(W1))
R1 (R): origin=0x1000 length=0x1000
R2 (R): origin=0x2000 length=0x1000
W1 (W): origin=0x3000 length=0x1000
}
SECTIONS {
.text: {} > FLASH // Inherits the FLASH_GROUP SECURE_GROUP, reading from ranges R1 and R2 and
// writing to range W1
}
Floating-point Options Update
The ‘-mfpu=none’ has been deprecated and replaced with ‘-mfpu=f32’ to indicate that floating point operations are available. ‘-mfpu=none’ is reserved and may be un-deprecated and redefined at a future date.
Interlinking ‘-mfpu=f64’ Code With ‘-mfpu=f32’ Libraries
In the 1.0.0.LTS release, trying to link common ‘-mfpu=f32’ libraries into an otherwise ‘-mfpu=f64’ project failed in the linker. In 2.0.0.STS, linking f32 libraries into an f64 project is allowed. Linking f64 libraries into an f32 project will still result in a linker error.
Performance/Code Size Improvements
- Elided many instances of unnecessary sign or zero extensions
- Improved performance of loops similar to strcmp or linked list search
- Improved identification of the saturation idiom which generates the MINMAXF instruction
- Eliminated excessive PAD instructions in a number of internal helper functions, improving code size
Fast Versions of C Library Functions
The following 32-bit floating point C library functions will be replaced much faster instruction sequences when ‘-ffast-math’ is enabled. For users not using ‘-ffast-math’, an associated builtin function may be available to generate the sequence.
- Inverse square root (1/sqrtf()) - There is no builtin for this operation
- sinf - __builtin_c29_sinf
- cosf - __builtin_c29_cosf
- fmodf - __builtin_c29_fast_fmodf
- roundf - __builtin_c29_fast_roundf
- floorf - __builtin_c29_fast_floorf
- truncf - __builtin_c29_fast_truncf
- ceilf - __builtin_c29_fast_ceilf
- atan2f - __builtin_c29_fast_atan2f
- acosf - __builtin_c29_fast_acosf
- asinf - __builtin_c29_fast_asinf
- logf - __builtin_c29_fast_logf
Note: These sequences may not be as precise as the standard C library function.
Host Support / Dependencies
The following host-specific versions of the 2.0.0.STS c29clang compiler tools are available:
- Linux: Ubuntu 18, RHEL 8
- Windows: 7, 8, 10
- Mac: OSX
Device Support
The c29clang compiler tools support development of applications that are to be loaded and run on one of the following processor and runtime environment configurations:
Runtime Environment Configuration | Options |
---|---|
C29 (default) | “-mcpu=c29.c0” |
Floating Point 32bit hardware ops, 64bit emulation (default) | “-mfpu=f32” |
Floating Point 32bit and 64bit hardware ops | “-mfpu=f64” |
Resolved Defects
ID | Summary |
---|---|
CODEGEN-14112 | Allow interlinking of f64/f32 |
CODEGEN-13728 | Secure return erroneously clears return value register |
CODEGEN-13642 | MacOS: missing symbol frmo Mac libc++.1.dylib may cause link to fail |
CODEGEN-13591 | clock() causes an illegal memory access |
CODEGEN-13507 | Loop fails to execute as many times as expected |
CODEGEN-13315 | Protected calls to and returns from some C library functions zero out argument/return registers |
CODEGEN-13175 | Linker does not preserve argument/return values when generating trampolines/landing pads to static functions |
Known Defects
The up-to-date known defects in v2.0.0.STS can be found here (dynamically generated):
End of File