Re: Support for named address spaces in C++
Andrew Pinski via Gcc schrieb: On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc wrote: Hi all, I’ve added a named address space to our backend and I noticed that it is only support in C. Has anyone had experience porting this feature to C++? Is there any technical reason why it’s not supported? The main issue is how it is interacts with templates and then mangling. There was a few other issues that have been posted about before every time it is raised. Thanks, Andrew AFAIK llvm / clang supports named address spaces in C++, so it is obviously possible and feasible. Johann
Re: Support for named address spaces in C++
On Fri, Jun 26, 2020 at 9:12 AM Georg-Johann Lay wrote: > > Andrew Pinski via Gcc schrieb: > > On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc > > wrote: > >> Hi all, > >> > >> I’ve added a named address space to our backend and I noticed that it is > >> only support in C. > >> Has anyone had experience porting this feature to C++? Is there any > >> technical reason why it’s not supported? > > > > The main issue is how it is interacts with templates and then > > mangling. There was a few other issues that have been posted about > > before every time it is raised. > > > > Thanks, > > Andrew > > > > AFAIK llvm / clang supports named address spaces in C++, so it is > obviously possible and feasible. I suppose restricting it to interfaces with extern "C" might side-step most of the mangling and template issues. Does clang document its C++ language extension? Richard. > > Johann >
Re: TLS Implementation Across Architectures
* Nathan Sidwell: > On 6/25/20 2:34 PM, Joel Sherrill wrote: >> Hi >> >> RTEMS supports over 15 processor architectures and we would like to ensure >> that TLS is supported on all rather than just a handful of popular ones >> (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document ( >> https://www.akkadia.org/drepper/tls.pdf) but it is a few years old and >> covers only a subset of architectures. >> >> Is TLS supported on all architectures in GCC? >> >> Is there some documentation on how it is implemented on architectures not >> in Ulrich's paper? Or some guidance on how to extract this information from >> the GCC source? > > The ARM (32) abi has some extensions to that, which originally came from > Alex Oliva and then I implemented (The GNU2 TLS stuff). I think the > smarts is in the linker for that though. There's a lot of complexity, created by lazy binding of TLS symbols, allocation of TLS data on first use (which simply crashes in low memory conditions), and support for dlopen (and dynamic linking in general). I'm not sure how much of that applies in the context of RTEMS.
DWARF subregs
Hi all, I'm trying to implement DWARF output for the AMD GCN target, and I've run into trouble; -O0 debug works pretty well, but there are some problems accessing variables in registers. Problem 1 The proposed DWARF specification for the target doesn't specify separate DWARF registers for the high and low parts of certain 64 bit registers (specifically EXEC and VCC), even though the hardware does. Instead, one is expected to specify that EXEC_HI and VCC_HI are parts of EXEC and VCC, but I'm pretty sure GCC can't do that. How can I express that in DWARF, and how should I go about implementing it in GCC? I think dwarf2out.c will need patching, but some clues about where would be welcome. Problem 2 The GCN architecture makes it common to have scalars located in vector registers (these are used with the other lanes masked off). I have no problem expressing, in the DWARF, which register holds the variable, but rocgdb still wants to treat the value as a vector, which doesn't work so well in complex DWARF expressions. The proposed DWARF specification includes a new directive "DW_OP_LLVM_push_lane" to handle this, but of course GCC does not support this yet. How can I best implement this new feature, both in dwarf2out and in the target hooks? The proposed standard changes are here: http://llvm.org/docs/AMDGPUUsage.html#dwarf-debug-information http://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html Thanks in advance Andrew
Re: WWDC thread: support for darwin/macOS going forward
On Jun 22, 2020, at 3:51 PM, Eric Gallager wrote: > > Hi, at Apple's WWDC this year they have announced that they are doing > yet another architecture transition, so I was wondering what exactly > would be the best way to go about adding support for it? I usually use emacs and git to add ports to gcc. Just email the changes into the patches list and someone will approve them, then you check them in. All pretty trivial and standard. The hard part, the base port to the CPU is already done, so mainly just finishing touches and polishing. If you want to do the work and need a little hand holding through the process, I'd like to think we have enough people to help get you started. Another completely different way, would be to find the right type of person that can do the port for $500, and offer them money. I once did a port to a brand new architecture for $100 when I was in school. That port brought up emacs, gcc, bash and a some other real nice to have bits of software. It was a great learning experience and I used that emacs and bash a lot, so, the end result was even useful. So, do you want to contribute patches? The neat thing about saying yes, is that you might find others that have time or inclination to also contribute, but that would rather contribute to something already underway rather than be the first.
G
Sent from my iPhone
gcc-9-20200626 is now available
Snapshot gcc-9-20200626 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200626/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 57096f5c52be8c5f0c29663234f31845bb172216 You'll find: gcc-9-20200626.tar.xzComplete GCC SHA256=b1d9f57a4a96bab106eccc64e3c10951bc7c1a3c57716c50f01beab66cd10d1d SHA1=5c1f8a6796ffef710a68bf8e53d604d6bc661593 Diffs from 9-20200619 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Hoisting DFmode loads out of loops..
On Fri, 2020-06-26 at 01:24 +, Alan Lehotsky wrote: > > On Jun 25, 2020, at 6:37 PM, Jeff Law wrote: > > > > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote: > > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit > > > data-path between registers and memory; > > > > > > looking at the gcc.dg/loop-9.c test, I fail to pass because I have split > > > the move of a double constant to memory into multiple moves (4 in fact, > > > because I only have a 16-bit immediate mode.) > > > > > > The (define_insn_and_split “movdf” …) is conditioned on > > > “reload_completed”. > > > > > > Is there some other trick I need get the constant hoisted. I have > > > already set the rtx cost of the CONST_DOUBLE ridiculously high (like 10 > > > insns) > > Hi Alan, it's been a long time... > > > > We'd probably need to set the RTL. A variety of things can get in the way > > of > > LICM. For example, I'd expect subregs to be problematical because they can > > look > > like RMW operations. > > > > jeff > > > > > Hello to you too, Jeff…. I’ve been lurking for the last decade or so, last > port I actually did was was GCC 4 based, so lots of new stuff to try and wrap > my head around. I certainly am grateful for anybody with suggestions as to > how to track down this problem (I’m not terribly eager to do a > parallel stepping thru a x86 gcc in parallel with my port to see where they > diverge in the loop-invariant recognition.) > > Although in crafting this expanded email, I see that the x86 has already > decided to store the constant 18.4242 in the .rodata section by the start of > loop-invariance so there’s a > > (set (reg:DF…. ) (mem:DF (symbol_ref ….))) > > and I bet that’s far easier to move out of the loop than it would be to split > the original > > (set (mem:DF…) (const_double:DF ….)) Yea, the former is definitely easier to apply LICM since we just have to disambiguate the load against any stores in the loop. The latter would have to disamgiguate against the loads in the loop and possibly the stores as well. I don't think loop-invariant.c would do anything with either form though. LCM (aka PRE) would probably have the best chance to handle the first form. And, yup, that's where it gets handled on x86. jeff >
Re: Customized coverage instrumentation for multiple C files
Any idea on that? I just cannot find a way of using GIMPLE to analyze multiple .C files. All my analysis is still start from the following function: virtual unsigned int execute(function *fun) override which has no idea about the .C file information. In LLVM all .C files are roughly maintained in separate "modules" but I just don't know how to access such information in GIMPLE. Best, Shuai On Thu, Jun 25, 2020 at 4:07 PM Shuai Wang wrote: > Hello, > > I am working on a basic block coverage counter which > mimics -fsanitize-coverage=trace-pc but has more features. My problem is > that when instrumenting multiple C files (e.g., test1.c test2.c test3.c), I > want to generate correspondingly three coverage logs (test1.log, test2.log, > test3.log), so on and so forth. > > Therefore, my question is 1) how to figure out the instrumented source > code file name in GIMPLE plugins (my plugins is after the "optimized" > pass), and 2) I want to keep all covered basic block info in memory and > write log file *only once* right before finish the profiling (i.e., the > instrumented program finish executing the program and is about to exit). > Can I somehow set a callback at that point and then flush the coverage > record into files? I don't know how/where to "set a callback" like that, if > possible at all. > > Thank you very much. > > Best, > Shuai >
Passing an string argument to a GIMPLE call
Hello,
I am writing the following statement to make a GIMPLE call:
tree function_fn_type = build_function_type_list(void_type_node,
void_type_node, integer_type_node, NULL_TREE);
tree sancov_fndecl = build_fn_decl("my_instrumentation_function",
function_fn_type);
auto gcall = gimple_build_call(sancov_fndecl, 2,
build_string_literal(3, "foo"), build_int_cst_type(integer_type_node, 0));
However, when executing the GIMPLE plugin, while inducing no internal
crash, the following function call statement is generated:
my_instrumentation_function (*&"foo"[0]*, 0);
The first argument seems really strange. Can I somewhat just put a "foo"
there instead of the current form? Thank you very much.
Best,
Shuai
