I'm aware of similar questions here and here, however, the LLVM codebase changes so quickly I'm here to ask if the state of things have changed since then.
So, currently I'm trying to write an out-of-tree pass that works on the whole program CFG (hence the need for the merged bitcode). I would prefer to use the legacy PassManager as opposed to the Mixin-based NPM due to some other legacy passes my current pass relies on.
clang is called with these args:
clang -flto -Xclang -O0 -Xclang -load -Xclang ./mvxaa.so -fuse-ld=gold -o ./tests/target_app $(TARGET_SOURCES)
Will this register the pass as an LTO (full) pass? The pass never runs.
static void registerGlobalCollectionPass(const PassManagerBuilder &PB,
legacy::PassManagerBase &PM) {
PM.add(new CollectGlobals());
}
static RegisterStandardPasses
RegisterMyPass(PassManagerBuilder::EP_FullLinkTimeOptimizationEarly,
registerGlobalCollectionPass);
Looking deeper, it seems that PassManagerBuilder::addExtensionsToPM is called by the individual populateXPassManager functions and they will look through the GlobalExtensions list to call the respective callback functions. For other non-LTO ExtensionPointTy like EP_EnabledOnOptLevel0 there are entries, but when populateLTOPassManager is called, there are no longer any entries in the GlobalExtensions smallvector. Why is this the case?
Is it because LTO occurs at a later point after the linker runs and the -load argument given to dlopen the shared libraries only loads the shared objects at the compilation phase?
Related
I have a cc_toolchain configuration for a proprietary c compiler and I have ensured that the compilation commands are correct from the bazel output using the '-s' flag.
However, bazel adds the three compilation flags '-MD -MF and -frandom-seed' in addition to what I have specified.
My compiler does not recognize the -MD and -MF flags. No issues with the -frandom-seed.
How can I specify bazel NOT to add these flags?
To not add random seed, disable the corresponding feature, add:
random_seed_feature = feature(
name = "random_seed",
enabled = False,
)
and add random_seed_feature to list of features you pass to cc_common.create_cc_toolchain_config_info().
For -MD -MF it gets more complicated. You could disable dependency_file feature in a similar manner, but the hdrs_check would fail expecting to find a dependency dump and I do not believe you can actually disable that for C++ action with cc_toolchain based on current implementation (or no readily available method comes to mind).
The question is, does your compiler still support dumping dependencies, just using different flag(s)? Then you can (even should) redefine the feature, for reference in https://github.com/bazelbuild/rules_cc it currently for U*X-like systems looks like this:
dependency_file_feature = feature(
name = "dependency_file",
enabled = True,
flag_sets = [
flag_set(
actions = [
ACTION_NAMES.assemble,
ACTION_NAMES.preprocess_assemble,
ACTION_NAMES.c_compile,
ACTION_NAMES.cpp_compile,
ACTION_NAMES.cpp_module_compile,
ACTION_NAMES.objc_compile,
ACTION_NAMES.objcpp_compile,
ACTION_NAMES.cpp_header_parsing,
ACTION_NAMES.clif_match,
],
flag_groups = [
flag_group(
flags = ["-MD", "-MF", "%{dependency_file}"],
expand_if_available = "dependency_file",
),
],
),
],
)
If your compiler does not produce this file at all, I am afraid on top of disabling the feature you'd need to wrap its call and dump an empty file to where dependency_file is expected (essentially use a flag the wrapper understands, gets the file name and strips both from compiler call, writing an empty file for the check). You'd lose the headers checking for dependencies being correctly declared by by-passing it, but it would allow the build to proceed.
Alternatively, from scratch new cc_toolchain with own actions which does not incorporate the header checking could be an option.
I want to make code scanner and parser but I don't know why this error happens just by looking at the error log. The scanner takes the sample code and divides it into tokens, then returns what each of the tokens in the code is doing.The parser receives the values returned from the scanner and parses the code according to the rules.
It checks validity of grammar of sample code.
and finally this my error
lex.yy.o: In function main:
lex.yy.c:(.text+0x1d2a): multiple definition of main
y.tab.o:y.tab.c:(.text+0x861): first defined here
collect2: error: ld returned 1 exit status
You have defined main in both your files, but C only allows a single definition of main in a program, which is what the linker error is telling you.
The main in your scanner file has an invalid prototype (C hasn't allowed function definitions without a return type for almost 20 years) and also calls yylex only once, which is not going to do much. So it seems pretty well pointless. If you want to debug your scanner without using the parser,byou can link the scanner with -lfl; that library includes a definition of main which repeatedly calls yylex until end of file is signalled.
Instead of scattering printf calls through your scanner, you can just build a debugging version of the scanner using the --debug flag when you generate the scanner. That will print out a trace of all scanner actions.
I have started recently programming in Contiki. Currently I want to synchronize the timer of a set of nodes. To achieve this, I am using the functions of the header file timesynch.h. I include it as a normal h file at the top of my code. But whenever I try to use the functions inside it (timesynch_init() for instance) I get the following error message:
xmas_sync.co: In function process_thread_example_collect_process':
/home/user/contiki-2.7/examples/rime/xmas_sync.c:108: undefined reference totimesynch_init'
collect2: ld returned 1 exit status
make: *** [xmas_sync.native] Error 1
I do not know if I need to do something else to use these synchronization functions. My code is based on the collect example.
You need to enable timesync in application's or platform's configuration. On most platforms, it is not done by default.
To enable it in application's configuration, there are two options:
Modify Makefile to include this define in CFLAGS:
CFLAGS += -DTIMESYNCH_CONF_ENABLED=1
Create a project-conf.h file, change Makefile to enable including this file:
CFLAGS += -DPROJECT_CONF_H=\"project-conf.h\"
and enable the timesync in project-conf.h by adding this line
#define TIMESYNCH_CONF_ENABLED 1
Also, it looks like you're to build the example for the native (x86) platform. To build for a sensor node hardware platform, set the TARGET variable, e.g. run make TARGET=sky example-collect.
The question is about how to make clang print information on which loops (or other parts of code) have been vectorized. GCC has a command line switch named -ftree-vectorizer-verbose=6 to do this (or -fopt-info-vec in newer versions of GCC), but I couldn't find anything similar for clang. Does clang support this or my only option is to peek in the disassembly ?
clang has following options to print diagnostics related to vectorization:
-Rpass=loop-vectorize identifies loops that were successfully vectorized.
-Rpass-missed=loop-vectorize identifies loops that failed vectorization and indicates if vectorization was specified.
-Rpass-analysis=loop-vectorize identifies the statements that caused vectorization to fail.
Source: http://llvm.org/docs/Vectorizers.html
Looking through the clang source code, there are a couple vectorization passes in Transforms/Vectorize:
BBVectorize
LoopVectorize
SLPVectorize
The last three don't seem to have any arguments that will print things. But in inside BBVectorize there are a couple of options for printing things when clang is built debug:
bb-vectorize-debug-instruction-examination - When debugging is enabled, output information on the instruction-examination process
bb-vectorize-debug-candidate-selection - When debugging is enabled, output information on the candidate-selection process
bb-vectorize-debug-pair-selection - When debugging is enabled, output information on the pair-selection process
bb-vectorize-debug-cycle-check - When debugging is enabled, output information on the cycle-checking process
bb-vectorize-debug-print-after-every-pair -When debugging is enabled, dump the basic block after every pair is fused
That looks like it's about it.
Where can I find a complete list of Clang flags?
There are some, like -include-pch, that don't appear to be even listed in the man page. :(
I know that GCC uses some of the same flags, but it doesn't include documentation for stuff like -Os which I believe is only available in Clang. Is there a place where I can find a single, consolidated list of all the Clang options ever?
I don't know if this is exactly what you want. Maybe more options are described elsewhere, but I think you are interested in the Clang frontend options. By default, the options displayed seem to describe the "GCC-compatible driver".
clang -cc1 --help should give you what you want.
For Clang, they are listed in the diagnostics reference, which can be found on the documentation website here
There are many hidden options in LLVM:
clang --help-hidden
opt --help-hidden
If you want to get a complete list of warning flags, including hierarchies (IE which sub-flags are enabled by groups like -Wall), you can use the LLVM tool diagtool.
$ diagtool tree Will print the complete list of warnings clang supports.
$ diagtool tree -Wnon-gcc will print the warnings enabled by -Wnon-gcc.
The warnings are color-coded:
RED = it does nothing, exists only for GCC compatibility
GREEN = the warning is enabled by default
YELLOW = the flag enables new behavior
Finally, I wrote a short script if you're interested in viewing the diff between sets of flags (see image below)
For example: -Wall -> -Wall -Wextra ->-Wall -Wextra -Wnon-gcc:
https://twitter.com/GavinRayDev/status/1599126252136280064
https://gist.github.com/GavinRay97/c28ca31a86f6a106bb46e426e2603be0
Here is a set of flags not enabled by your typical -Wall -Wextra -Wpedantic for Clang (as of LLVM 16 dev) you might find useful, that I scraped from the output of diagtool:
https://gist.github.com/GavinRay97/bae1d93925e55ce0a0084946f24984cf
Hope someone out there finds this information useful =)