This is an alternative approach for D131469.
The difference in behavior compared to D131469 is that instead of looking for linking jobs, here if a "main" output is available ('-o <output>' is given) the directory of it is used for '-ftime-trace'.
Another is that time traces in offloading tool-chain (e.g. CUDA or HIP) compilation steps are also supported by saving them to the same directory as the host trace, with naming similar to '-save-temps'.
If '-save temps' is on the file type suffix is also included to keep the trace from e.g the front-end compilation overwriting the back-end trace.
The final behavior is this:
- if '-ftime-trace=path/to/trace.json' is given, then use it for the final compilation, and use the directory where it is for the rest (offloading or '-save-temps')
- if '-ftime-trace=path/to/trace/folder' is given:
- for the main output use 'path/to/trace/folder/<output-name>,json' if '-o <output-name>.o' is given
- if no output path is specified or for the rest of the files use 'path/to/trace/folder/<input-name>.json' similar to '-save-temps'
- if '-ftime-trace' is given and there is a main output ('-o output') use the directory of it to store the traces
- if '-ftime-trace' but no '-o <output>' use the current working directory
The patch also drops '-ftime-trace' from cc1 options as the driver now always passes the full path in '-ftime-trace=<path>'
I don't think we should use a non-zero inline element for these members.
They are, in 99.9% cases, empty. We should optimize for the member size by making the number of inline element to 0.