Re: [PATCH] shrink-wrap: Fix up partitions (PR67587)

On 09/16/2015 02:17 AM, Segher Boessenkool wrote: With the new shrink-wrap algorithm, blocks reachable both with and without prologue are duplicated, and their incoming edges are then distributed accordingly. So we need to call fixup_partitions. Is this okay for trunk? I think so, given that

Re: [patch] Get rid of useless EH cleanups at -O0

On 09/14/2015 11:56 AM, Eric Botcazou wrote: this patchlet makes it possible to get rid of useless EH cleanups generated at -O0 in Ada for simple constructs involving VLAs: declare S : String (1 .. N); begin ... end; by duplicating finally blocks that contain only a stack

Re: [patch] Bump size of stack checking protection area

On 09/15/2015 09:50 AM, Eric Botcazou wrote: It's not Ada-specific in the sense that, if you want to raise an exception on a stack overflow in any language with the middle-end SJLJ scheme, the current setting is definitely not sufficient and you'll get a crash during unwinding. For avoidance

Re: [patch] Get rid of useless EH cleanups at -O0

On 09/14/2015 11:56 AM, Eric Botcazou wrote: 2015-09-14 Eric Botcazou * tree-eh.c (lower_try_finally_dup_block): Clear location information on stack restore statements. (decide_copy_try_finally): Do not consider a stack restore statement as

Re: [PATCH] Target hook for disabling the delay slot filler.

On 09/15/2015 04:19 PM, Simon Dardis wrote: This patch adds a target hook for disabling the eager delay slot filler which when disabled can give better code. No new regressions. Ok to commit? Hmm. Whether a branch was filled by the simple or eager filler is an implementation detail - is

Re: [PATCH 00/22] RFC: Overhaul of diagnostics

On 09/10/2015 10:28 PM, David Malcolm wrote: Attached is a work-in-progress patch kit implementing these ideas. I posting it now to get feedback: some parts of it may be ready to commit, but other parts are definitely *not* ready yet. It's hard to provide meaningful review under these

Re: [PATCH] PR28901 -Wunused-variable ignores unused const initialised variables

On 09/13/2015 08:24 PM, Mark Wielaard wrote: commit 97505bd0e4ac15d86c2a302cfebc5f1a4fc2c2e8 Author: Mark Wielaard Date: Fri Sep 11 23:54:15 2015 +0200 PR28901 -Wunused-variable ignores unused const initialised variables in C This is ok. Bernd

Re: [PATCH] v2 shrink-wrap: Rewrite

* shrink-wrap.c (requires_stack_frame_p): Fix formatting. (dup_block_and_redirect): Delete function. (can_dup_for_shrink_wrapping): New function. (fix_fake_fallthrough_edge): New function. (try_shrink_wrapping): Rewrite function.

Re: Split up optabs.[hc]

On 09/14/2015 07:54 PM, Richard Sandiford wrote: This patch splits optabs up as follows: - optabs-query.[hc]: IL-independent functions for querying what a target can do natively. - optabs-tree.[hc]: tree and gimple query functions (an extension of optabs-query.[hc]). -

Re: [PATCH diagnostics/67460] Replace some_warnings_are_errors with diagnostic_kind_count (context, DK_WERROR)

On 09/14/2015 01:45 AM, Manuel López-Ibáñez wrote: The flag diagnostic_context::some_warnings_are_errors controls whether to give the message "all warnings being treated as errors". However, when warnings are buffered and then discarded, this flag is not reset. It turns out we do not need this

Re: [PATCH] PR67401: Fix wrong code generated by expand_atomic_compare_and_swap

On 09/11/2015 05:15 PM, John David Anglin wrote: On 2015-09-11 4:15 AM, Bernd Schmidt wrote: On 09/11/2015 01:21 AM, John David Anglin wrote: As noted in the PR, expand_atomic_compare_and_swap can generate wrong code when libcalls are emitted for the sync_compare_and_swap and the result

Update my email address.

Committed. Bernd Index: ChangeLog === --- ChangeLog (revision 227737) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2015-09-14 Bernd Schmidt <bschm...@redhat.com> + + * MAINTAINERS: Update my email address. + 2015-09-01

Re: [patch] Bump size of stack checking protection area

On 09/14/2015 10:23 AM, Eric Botcazou wrote: as documented, STACK_CHECK_PROTECT is supposed to be an "estimate of the amount of stack required to propagate an exception". It's (mainly) for Ada and it needs to distinguish the various EH schemes, which might have different needs. While the

Re: [gomp4] SESE region neutering

On 09/11/2015 11:49 PM, Nathan Sidwell wrote: This patch implements that optimization. As the comment at the head of the code says, we first find 'cycle-equivalent' BBs. These are ones that we determine are in the same (set of) loops, in the closed graph. Such equivalent BBs form the entry and

Re: [PATCH][PR67476] Add param parloops-schedule

On 09/11/2015 03:28 PM, Tom de Vries wrote: This patch adds handling of a DEFPARAMENUM macro, which is similar to the DEFPARAM macro, but allows the values to be named. So the definition of param parloop-schedule becomes: ... DEFPARAMENUM PARAM_PARLOOPS_SCHEDULE,

Re: [PATCH 2/2] shrink-wrap: Rewrite try_shrink_wrapping

On 09/10/2015 05:14 PM, Segher Boessenkool wrote: This patch rewrites the shrink-wrapping algorithm, allowing non-linear pieces of CFG to be duplicated for use without prologue instead of just linear pieces. An example would be good for this kind of patch, also in the comments. -

Re: [Patch] Teach RTL ifcvt to handle multiple simple set instructions

On 09/10/2015 11:11 PM, Jeff Law wrote: I think that's probably what James is most interested in getting some ideas around -- the cost model. I think the fundamental problem is BRANCH_COST isn't actually relative to anything other than the default value of "1". It doesn't directly correspond

Re: [PATCH] PR67401: Fix wrong code generated by expand_atomic_compare_and_swap

On 09/11/2015 01:21 AM, John David Anglin wrote: As noted in the PR, expand_atomic_compare_and_swap can generate wrong code when libcalls are emitted for the sync_compare_and_swap and the result comparison test. This is fixed by emitting a move insn to copy the result rtx of the

Re: [PATCH] PR28901 -Wunused-variable ignores unused const initialised variables

On 09/12/2015 12:12 AM, Mark Wielaard wrote: 12 years ago it was decided that -Wunused-variable shouldn't warn about static const variables because some code used const static char rcsid[] strings which were never used but wanted in the code anyway. But as the bug points out this hides some real

Re: [PATCH] Teach genmatch.c to generate single-use restrictions from flags

On 07/08/2015 04:39 PM, Richard Biener wrote: This introduces a :s flag to match expressions which enforces the expression to have a single-use if(!) the simplified expression is larger than one statement. This seems to be missing documentation in match-and-simplify.texi. Bernd

Re: [PATCH 2/2] shrink-wrap: Rewrite try_shrink_wrapping

On 09/11/2015 02:36 PM, Segher Boessenkool wrote: I'm wondering how your new algorithm prevents the prologue from being placed inside a loop. Can you have a situation where this picks a predecessor that is reachable but not dominated by PRO? It doesn't prevent it! The prologue will not be

Re: Ping^2 Re: Pass -foffload targets from driver to libgomp at link time

On 09/11/2015 04:23 PM, Joseph Myers wrote: On Thu, 10 Sep 2015, Bernd Schmidt wrote: On 09/10/2015 03:41 PM, Joseph Myers wrote: Ping^2. This patch <https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01748.html> is still pending review. No fundamental objections, but I have some que

Re: [PATCH 3/3] stop including tm.h in sendmsg.c

On 09/10/2015 01:57 PM, tbsaunde+...@tbsaunde.org wrote: > From: Trevor Saunders > > libobjc/ChangeLog: > > 2015-09-10 Trevor Saunders > > * sendmsg.c (tm.h): Remove include. Ok for this and the previous one too. If it turns out

Re: [PATCH 1/3] remove STRUCT_VALUE macro

On 09/10/2015 01:57 PM, tbsaunde+...@tbsaunde.org wrote: > From: Trevor Saunders > > It is undocumented so the meaning is unclear, but it is only ever > defined to 0, which the one user in libobjc treats the same as being > undefined. Apparently it was converted to

Re: Ping^2 Re: Pass -foffload targets from driver to libgomp at link time

On 09/10/2015 03:41 PM, Joseph Myers wrote: > Ping^2. This patch > is still > pending review. No fundamental objections, but I have some questions. Cuold you describe what the handling of flags/lang_mask accomplishes in this patch?

Re: [PATCH 1/2] shrink-wrap: Header hygiene

On 09/10/2015 05:14 PM, Segher Boessenkool wrote: > > * shrink-wrap.c (requires_stack_frame_p): Make static. > (prepare_shrink_wrap): Likewise. > (dup_block_and_redirect): Likewise. > * shrink-wrap.h: Remove declarations of those functions. This is ok. Bernd

Re: [Patch] Teach RTL ifcvt to handle multiple simple set instructions

On 09/08/2015 04:53 PM, James Greenhalgh wrote: One big question I have with this patch is how I ought to write a meaningful cost model I've used. It seems like yet another misuse of RTX costs, and another bit of stuff for targets to carefully balance. Now, if the relative cost of branches and

MAINTAINERS: Update my email address

to work in that area and is likely to make the majority of all changes to it in the near future. Bernd commit 706c66066e216ad5b9f0b807a4640aa3ef6990c3 Author: Bernd Schmidt ber...@codesourcery.com Date: Thu Jul 23 20:02:45 2015 +0200 * MAINTAINERS: Update my email address. diff --git

Some additional comments for nvptx.c

Nathan asked me to go through nvptx.c and update some comments for things that aren't completely obvious. I've committed the following to trunk. Bernd Index: gcc/config/nvptx/nvptx.c === --- gcc/config/nvptx/nvptx.c (revision

Re: [gomp4] New nvptx pattern and internal builtin

On 07/20/2015 03:19 PM, Nathan Sidwell wrote: I was looking at adding another target builtin, and found this code rather convoluted. It seemed to have been cloned from somewhere more complicated -- for instance, nvptx_expand_binop_builtin's comment discusses a MACFLAG argument, which is

[gomp4] New nvptx pattern and internal builtin

/ChangeLog.gomp === --- gcc/ChangeLog.gomp (revision 225936) +++ gcc/ChangeLog.gomp (working copy) @@ -1,3 +1,17 @@ +2015-07-17 Bernd Schmidt ber...@codesourcery.com + + * config/nvptx/nvptx.c (enum nvptx_builtins, + struct

Re: [nvptx] C++ify mkoffloads

On 07/15/2015 08:55 PM, Nathan Sidwell wrote: I've applied this obvious patch to trunk to make mkoffloads work for C++. The equivalent is already on the gomp4 branch. Not really objecting, but why is this necessary? We control how to compile the file generated by mkoffload, so we can just

Re: [GOMP] a struct for offload target data

On 07/13/2015 03:57 PM, Nathan Sidwell wrote: this patch changes the offload target data type from an array of void *, to a struct, which is somewhat easier to deal with than remembering numeric indices and type casts. This is step 1 in reworking the launch API. Looks fine. Bernd

Re: [nvptx] mkoffload cleanup

On 07/11/2015 12:53 AM, Nathan Sidwell wrote: I'mm working through the mkoffload machinery. mkoffload.c emits a C file, and the quoting in the source is quite confusing. This patch introduces a quoting macro 'Q' that allows one to write raw C to be stringized and written out. ok? (more

Re: [PATCH] config/bfin/bfin.c (hwloop_optimize): Use return false instead of gcc_assert for checking jump_insn.

On 07/03/2015 04:13 AM, Chen Gang wrote: On 07/01/2015 11:27 PM, Chen Gang wrote: On 7/1/15 21:52, Bernd Schmidt wrote: Below is a patch. Can you test this with anything you have beyond the testsuite? It can fix this issue (Bug66620), let the insns standard, and can build the bfin kernel

Re: [PATCH] config/bfin/bfin.c (hwloop_optimize): Use return false instead of gcc_assert for checking jump_insn.

On 07/01/2015 03:04 AM, Chen Gang wrote: For me, the more details are: - The insns have 2 loops which can be lsetup optimized. - After hwloop_optimize finishes 1st lsetup optimization, it generates new lsetup insn which appends to jump insn in the basic block (which causes the

Re: [PATCH] config/bfin/bfin.c (hwloop_optimize): Use return false instead of gcc_assert for checking jump_insn.

On 06/28/2015 04:15 PM, Chen Gang wrote: For bfin looping optimization, after lsetup optimization, it can have the correct lsetup related insns which causes gcc_assert for jump_insn. I've been debugging this for a bit, and at least the explanation of the patch is wrong - it's finding an

Re: [patch] fix regrename pass to ensure renamings produce valid insns

On 06/25/2015 03:53 PM, Eric Botcazou wrote: I'd be happiest if we had an assert on almost all targets. regrename has been designed in such a way that the replacements can't fail, if the constraints on the insns are correct. If there are ports which have borderline insns where that doesn't hold

Re: [patch] fix regrename pass to ensure renamings produce valid insns

On 06/25/2015 05:46 AM, Jeff Law wrote: As Eric mentioned, please put an assert to verify that the call from the c6x backend never fails. I'd be happiest if we had an assert on almost all targets. regrename has been designed in such a way that the replacements can't fail, if the constraints

Re: [gomp4] Preserve NVPTX reconvergence points

On 06/19/2015 03:45 PM, Jakub Jelinek wrote: If the loop remains in the IL (isn't optimized away as unreachable or isn't removed, e.g. as a non-loop - say if it contains a noreturn call), the flags on struct loop should be still there. For the loop clauses (reduction always, and

Re: [gomp4] Preserve NVPTX reconvergence points

On 06/22/2015 04:24 PM, Jakub Jelinek wrote: I don't understand why lowering the way you suggest helps here at all. In the proposed scheme, you essentially have whole function in e.g. worker-single or vector-single mode, which you need to be able to handle properly in any case, because users can

Re: [gomp4] Preserve NVPTX reconvergence points

On 06/19/2015 03:45 PM, Jakub Jelinek wrote: I actually believe having some optimization passes in between the ompexp and the lowering of the IR into the form PTX wants is highly desirable, the form with the worker-single or vector-single mode lowered will contain too complex CFG for many

Re: [gomp4] Preserve NVPTX reconvergence points

On 06/19/2015 02:25 PM, Jakub Jelinek wrote: Emitting PTX specific code from current ompexp is highly undesirable of course, but I must say I'm not a big fan of keeping the GOMP_* gimple trees around for too long either, they've never meant to be used in low gimple, and even all the early

Re: [gomp4] Preserve NVPTX reconvergence points

On 05/28/2015 05:08 PM, Jakub Jelinek wrote: I understand it is more work, I'd just like to ask that when designing stuff for the OpenACC offloading you (plural) try to take the other offloading devices and host fallback into account. The problem is that many of the transformations we need to

Re: [gomp4] Worker-single predication

On 06/02/2015 01:06 PM, Thomas Schwinge wrote: On Mon, 1 Jun 2015 17:58:51 +0200, Bernd Schmidt ber...@codesourcery.com wrote: This extends the previous vector-single support to also handle worker-level predication. [...] This causes the following regressions; would you please have a look

Re: [gomp4] Avoiding predication for certain blocks

On 06/01/2015 12:10 PM, Tom de Vries wrote: On 29/05/15 18:23, Bernd Schmidt wrote: When predicating the code for OpenACC, we should avoid the entry block in an offloaded region, which contains setup code that should be run in every thread. The following patch adds a new marker statement

[gomp4] Worker-single predication

/ChangeLog.gomp === --- gcc/ChangeLog.gomp (revision 223974) +++ gcc/ChangeLog.gomp (working copy) @@ -1,3 +1,29 @@ +2015-06-01 Bernd Schmidt ber...@codesourcery.com + + * gimple.h (struct gimple_statement_omp_parallel_layout): Add

[gomp4] Avoiding predication for certain blocks

+1,18 @@ +2015-05-29 Bernd Schmidt ber...@codesourcery.com + + * gimple.def (GIMPLE_OMP_ENTRY_END): New code. + * gimple.h (gimple_build_omp_entry_end): Declare. + (CASE_GIMPLE_OMP): Add GIMPLE_OMP_ENTRY_END. + * gimple.c (gimple_build_omp_entry_end): New function. + * gimple-low.c (lower_stmt

[gomp4] A thread barrier builtin

(working copy) @@ -1,5 +1,13 @@ 2015-05-29 Bernd Schmidt ber...@codesourcery.com + * config/nvptx/nvptx.md (UNSPECV_BARSYNC): New constant. + (oacc_threadbarrier): New expander. + (threadbarrier_insn): New pattern. + * config/nvptx/nvptx.c (nvptx_cannot_copy_insn_p): + * omp-builtins.def

[gomp4] Initialize some extra variables at the entry to an OpenACC offloaded region

=== --- gcc/ChangeLog.gomp (revision 223870) +++ gcc/ChangeLog.gomp (working copy) @@ -1,5 +1,10 @@ 2015-05-29 Bernd Schmidt ber...@codesourcery.com + * omp-low.c (struct omp_context): Add worker_var and worker_count + fields. + (oacc_init_count_vars): New function. + (lower_omp_target

Re: [nvptx] Re: Mostly rewrite genrecog

On 05/21/2015 09:12 AM, Thomas Schwinge wrote: OK to commit? gcc/ * config/nvptx/nvptx.md (allocate_stack): Rename to... (allocate_stack_mode): ... this, and add :P on both match_operand and unspec. (allocate_stack): New expander. If you really want

[gomp4] Vector-single predication

) +++ gcc/ChangeLog.gomp (working copy) @@ -1,5 +1,15 @@ 2015-05-20 Bernd Schmidt ber...@codesourcery.com + * omp-low.c (struct omp_region): Add a gwv_this field. + (bb_region_map): New variable. + (find_omp_for_region_data, find_omp_target_region_data): New static + functions. + (build_omp_regions_1

[gomp4] New builtins, preparation for oacc vector-single

-19 Bernd Schmidt ber...@codesourcery.com + + * omp-builtins.def (GOACC_thread_broadcast, + GOACC_thread_broadcast_ll): New builtins. + * optabs.def (oacc_thread_broadcast_optab): New optab. + * builtins.c (expand_builtin_oacc_thread_broadcast): New function. + (expand_builtin): Use it. + * config

[gomp4] Unidirectional branches for nvptx

condition is constant across a warp, add .uni. Committed on gomp-4_0-branch. Bernd Index: gcc/ChangeLog.gomp === --- gcc/ChangeLog.gomp (revision 223443) +++ gcc/ChangeLog.gomp (working copy) @@ -1,3 +1,13 @@ +2015-05-20 Bernd Schmidt

Re: [gomp4] New builtins, preparation for oacc vector-single

On 05/20/2015 02:39 PM, Jakub Jelinek wrote: On Wed, May 20, 2015 at 02:01:44PM +0200, Bernd Schmidt wrote: To implement OpenACC vector-single mode, we need to ensure that only one thread out of the group representing a worker executes. The others skip computations but follow along the CFG, so

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

On 05/12/2015 06:27 PM, Thomas Schwinge wrote: Patch variant 1: @@ -4266,7 +4266,7 @@ process_command (unsigned int decoded_op } gcc_assert (!IS_ABSOLUTE_PATH (tooldir_base_prefix)); - tooldir_prefix2 = concat (tooldir_base_prefix, spec_host_machine, + tooldir_prefix2 = concat

Re: [PATCH 6/n] OpenMP 4.0 offloading infrastructure: option handling

On 04/27/2015 06:08 PM, Thomas Schwinge wrote: OK to do the following instead? (Coding style/code copied from gcc/config/i386/intelmic-mkoffload.c for consistency.) Err, was this a question for me? I'm fine with that too. Bernd

Re: [WIP] OpenMP 4 NVPTX support

On 04/21/2015 05:58 PM, Jakub Jelinek wrote: suggests that while it is nice that when building nvptx accel compiler we build libgcc.a, libc.a, libm.a, libgfortran.a (and in the future hopefully libgomp.a), nothing attempts to link those in :(. I have that fixed; I expect I'll get around to

Re: [PATCH] gcc/config/c6x/c6x.md: Remove clobber (match_scratch ...) in movmisalignmode_store.

). Bernd diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 8e4b6c1..d5535f9 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,5 +1,8 @@ 2015-03-27 Bernd Schmidt ber...@codesourcery.com + * config/c6x/c6x.md (movmisalignmode): Use MEM_P, not + memory_operand. + PR target/65052

Fix PR65052

432e3b7c5e3e47fdc9232805519d54f516c18008 Author: Bernd Schmidt ber...@codesourcery.com Date: Fri Mar 27 13:32:31 2015 +0100 Fix c6x-uclinux build failure. * config/c6x/constraints.md (S3): New constraint. * config/c6x/c6x.md (real_jump): Use it. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index

Re: Option overriding in the offloading code path

On 02/25/2015 11:28 AM, Thomas Schwinge wrote: Am I on the right track with my assumption that it is correct that nvptx.c:nvptx_option_override is not invoked in the offloading code path, so we'd need a new target hook (?) to consolidate/override the options in this scenario? I'm surprised by

Re: Another ptx offloading patch

=== --- gcc/ChangeLog (revision 220854) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,16 @@ +2015-02-20 Bernd Schmidt ber...@codesourcery.com + + * cgraph.h (clone_function_name_1): Declare. + * cgraphclones.c (clone_function_name_1): New function. + (clone_function_name): Use

Re: nvptx offloading patches [3/n], RFD

On 02/17/2015 05:40 PM, Jakub Jelinek wrote: On Tue, Feb 17, 2015 at 04:21:06PM +, Joseph Myers wrote: On Tue, 17 Feb 2015, Jakub Jelinek wrote: Third attempt failed with: ../../../libgcc/config/nvptx/realloc.c:24:20: fatal error: stdlib.h: No such file or directory compilation

Re: Offloading compilers' support libraries

On 02/19/2015 12:42 PM, Thomas Schwinge wrote: This specific buglet aside (that the handling of intelmic and nvptx offloading is inconsistent) -- will we have to add such handling to each and every library that is built for the offloading compilers? (Including libraries that aren't part of the

Re: nvptx offloading patches [2/n]

On 02/09/2015 11:16 AM, Richard Biener wrote: Thus, if your patch survives LTO bootstrap and you can still LTO a TU with ms_abi valist functions successfully (not sure if that's exercised in the testsuite) then it is fine. I've now done the LTO bootstrap, and the program below compiled with

Re: nvptx offloading patches [2/n]

On 02/17/2015 06:10 PM, Jakub Jelinek wrote: What exact testcase are you trying to fix with this patch, and how do you think offloading of code using va_list can work? The exact testcase is any offloaded program - streaming in lto will crash if there is a mismatch in these preloaded nodes.

Re: nvptx offloading patches [4/n]

On 02/11/2015 03:44 PM, Thomas Schwinge wrote: Note the global cold/hot labels. This confuses mkoffload, and it runs into a busy loop due to what I understand to be a bug in skipping of strange tokens, cited above, which such global labels would fall under. Here is what might be a fix for this

Re: Another ptx offloading patch

On 02/10/2015 11:34 AM, Richard Biener wrote: Bernds patch is ok with the unrelated gcc.c hunk removed. Thanks. I'm assuming this is for the next stage 1? Bernd

Re: Housekeeping work in backends.html

On 01/07/2015 12:39 AM, Eric Botcazou wrote: Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc). The page is directly browsable at https://gcc.gnu.org/backends.html For the moxie, nvptx, rl178

Re: [nvptx-tools, committed] Also install [...]/nvptx-none/bin/ar and [...]/nvptx-none/bin/ranlib.

On 12/23/2014 07:50 PM, Thomas Schwinge wrote: GCC needs this, if nvptx-none-ar and nvptx-none-ranlib aren't found in $PATH. I've pushed the three patches you sent to my github repository. Bernd

Re: RFC: Building a minimal libgfortran for nvptx

On 11/14/2014 10:28 PM, Tobias Burnus wrote: All in all: Okay when tesing succeeded. I still prefer some words what's excluded (or included) in minimal as comment in configure.ac, but the patch is also okay without. I thought you meant something more than adding a comment. I've added this in

Re: Bernd Schmidt appointed as nvptx port maintainer

On 11/21/2014 06:57 PM, Jeff Law wrote: Bernd, please add yourself as the maintainer for that port in the MAINTAINERS file. Thanks, done. Bernd

Re: LTO streaming of TARGET_OPTIMIZE_NODE

On 11/13/2014 05:06 AM, Jan Hubicka wrote: this patch adds infrastructure for proper streaming and merging of TREE_TARGET_OPTION. This breaks the offloading path via LTO since it introduces an incompatibility in LTO format between host and offload machine. A very quick patch to fix it is

Another ptx offloading patch

a dollar sign. The patch below does this at the lto-read stage. Bootstrapped on x86_64-linux, ok if testing is successful? Bernd commit 26b41de43c6db6e2368a9511c589c433b1e49c96 Author: Bernd Schmidt ber...@codesourcery.com Date: Wed Nov 19 21:47:59 2014 +0100 Renaming for invalid symbols

Re: OpenACC middle end changes

On 11/20/2014 07:52 AM, Jakub Jelinek wrote: On Thu, Nov 20, 2014 at 03:19:11AM +0100, Bernd Schmidt wrote: Thomas had apparently already pointed out an issue with the new gomp_target class (there are multiple similar types of statements we want to handle with OpenACC, they have different codes

Re: LTO streaming of TARGET_OPTIMIZE_NODE

On 11/20/2014 02:20 PM, Richard Biener wrote: On Thu, 20 Nov 2014, Bernd Schmidt wrote: On 11/13/2014 05:06 AM, Jan Hubicka wrote: this patch adds infrastructure for proper streaming and merging of TREE_TARGET_OPTION. This breaks the offloading path via LTO since it introduces

Re: OpenACC middle end changes

On 11/19/2014 02:50 AM, Bernd Schmidt wrote: @@ -8417,6 +8926,9 @@ expand_omp_target (struct omp_region *region) /* Add the new function to the offload table. */ vec_safe_push (offload_funcs, child_fn); + /* Add the new function to the offload table

Re: OpenACC middle end changes

Another change that's required is (something like) the following. For ptx, we need to know whether to output something as a .func (callable from ptx code) or a .kernel (callable from the host). That means we need to mark the kernel functions somehow in omp-low.c, and the following does that by

Re: The nvptx port

Hi Jakub, I have some questions about nvptx: 1) you've said that alloca isn't supported, but it seems to be wired up and uses the %alloca documented in the PTX manual, what is the issue with that? %alloca not being actually implemented by the current PTX assembler or translator?

Re: The nvptx port

On 11/14/2014 11:01 AM, Jakub Jelinek wrote: On Fri, Nov 14, 2014 at 09:29:48AM +0100, Jakub Jelinek wrote: I have some questions about nvptx: Oh, and 5) I have noticed gcc doesn't generate the .uni suffixes anywhere, while llvm generates them; are those appropriate only when a function

Re: system.h vs. C++ STL headers again

On 11/14/2014 12:03 PM, Jakub Jelinek wrote: On Fri, Nov 14, 2014 at 11:57:57AM +0100, Richard Biener wrote: ? There are also some comments about stdarg.h and stdio.h ordering, dunno what it comes from and if it is still relevant when we require C++ compiler. I think we should simply

Re: The nvptx port

I'm adding Thomas and Cesar to the Cc list, they may have more insight into CUDA library questions as I haven't really looked into that part all that much. On 11/14/2014 12:39 PM, Jakub Jelinek wrote: On Fri, Nov 14, 2014 at 12:09:03PM +0100, Bernd Schmidt wrote: I have some questions about

Re: The nvptx port

On 11/14/2014 01:36 PM, Jakub Jelinek wrote: Any way to query those limits? Size of .shared memory, number of threads in warp, number of warps, etc.? I'd have to google most of that. There seems to be a WARP_SZ constant available in ptx to get the size of the warp. In OpenACC, are all

Re: RFC: Building a minimal libgfortran for nvptx

Hi Tobias, Does printf work? I thought I/O is not supported? Or does it just accept it for linking and drop it? I think Janne's patch has already dealt with the issue of stack allocation. printf (or more accurately vprintf) is supported by ptx as a magic builtin function. We have a printf

ptx debugging patch

The situation with debugging on ptx is a little strange - it allows .file and .loc directives for line numbers, and it provides a way to define dwarf2 debug sections - but as far as I can tell, there's no way of putting useful or accurate information into the latter. There's also the slight

Re: nvptx offloading patches [3/n], i386 bits RFD

On 11/05/2014 01:19 AM, Bernd Schmidt wrote: On 11/04/2014 10:50 PM, Jeff Law wrote: No, I don't think it's terminology. It's really that in effect we have two targets. One is a normal CPU, the other is a GPU. ie, there's nothing that says we won't have a GPU that's being driven by an ARM

Re: nvptx offloading patches [2/n]

On 11/03/2014 11:23 PM, Jeff Law wrote: On 11/01/14 05:51, Bernd Schmidt wrote: LTO has a mechanism not to stream out common nodes that are expected to be identical on each run. When using LTO to communicate between compilers for different targets, the va_list_type_node and related ones must

Re: nvptx offloading patches [1/n]

On 11/05/2014 12:17 AM, Jeff Law wrote: On 11/04/14 14:08, Bernd Schmidt wrote: On 11/04/2014 10:01 PM, Jeff Law wrote: Communication between host and GPU is all done via some form of memcpy, so I wouldn't expect this to be a problem. They still need to agree on the layout of the structure

Re: [PATCH 2/5] combine: handle I2 a parallel of two SETs

On 11/14/2014 08:19 PM, Segher Boessenkool wrote: + /* If I2 is a PARALLEL of two SETs of REGs (and perhaps some CLOBBERs), + make those two SETs separate I1 and I2 insns, and make an I0 that is + the original I1. */ + if (i0 == 0 + GET_CODE (PATTERN (i2)) == PARALLEL +

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On 11/11/2014 09:30 AM, Eric Botcazou wrote: I just don't like all the as_a/is_a stuff enforced everywhere, it means more typing, more temporaries, more indentation. So, as I view it, instead of the checks being done cheaply (yes, I think the gimple checking as we have right now is very cheap)

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On 11/11/2014 09:30 AM, Eric Botcazou wrote: I just don't like all the as_a/is_a stuff enforced everywhere, it means more typing, more temporaries, more indentation. So, as I view it, instead of the checks being done cheaply (yes, I think the gimple checking as we have right now is very cheap)

Re: [7/7] nvptx testsuite patches: Return addresses

On 11/10/2014 09:19 PM, H.J. Lu wrote: I checked in this patch to revert the accidental checkin. Sorry about that, and thanks for fixing it. Bernd

Re: [2/6] nvptx testsuite patches: typed assembly

On 10/21/2014 05:32 PM, Bernd Schmidt wrote: On 10/21/2014 05:16 PM, Jeff Law wrote: On 10/21/14 14:15, Bernd Schmidt wrote: Since everything in ptx assembly is typed, KR C is problematic. There are a number of testcases that call functions with the wrong number of arguments, or arguments

Re: The nvptx port [10/11+] Target files

commit 659744a99d815b168716b4460e32f6a21593e494 Author: Bernd Schmidt ber...@codesourcery.com Date: Thu Nov 6 19:03:57 2014 +0100 Add the nvptx port. * configure.ac: Handle nvptx-*-*. * configure: Regenerate. gcc/ * config/nvptx/nvptx.c: New file. * config

Re: The nvptx port [8/11+] Write undefined decls.

On 10/22/2014 08:11 PM, Jeff Law wrote: I'm not going to insist you do this in the same way as the PA. That was a different era -- we had significant motivation to make things work in such a way that everything could be buried in the pa specific files. That sometimes led to less than optimal

Re: The nvptx port [10/11+] Target files

On 11/04/2014 05:51 PM, Bernd Schmidt wrote: On 11/04/2014 05:48 PM, Richard Henderson wrote: On 10/28/2014 03:56 PM, Bernd Schmidt wrote: +nvptx_ptx_type_from_mode (enum machine_mode mode, bool promote) +{ + switch (mode) +{ +case BLKmode: + return .b8; +case BImode

Re: nvptx offloading patches [3/n], i386 bits RFD

On 11/03/2014 11:27 PM, Jeff Law wrote: On 11/01/14 05:57, Bernd Schmidt wrote: This is not against current trunk; it applies to gomp-4_0-branch where it is one of the necessary parts to make offloading x86-nvptx work. The issue is that the LTO file format depends on the machine_modes enum

RFC: Building a minimal libgfortran for nvptx

The ptx port by its nature is lacking features that are expected on normal machines, such as alloca and indirect jumps. We have a subset of the C library which contains functions that can be implemented on the target (excluding things like file I/O other than printf which is a ptx builtin).

Re: The nvptx port [1/11+] indirect jumps

On 10/20/2014 04:19 PM, Bernd Schmidt wrote: ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be defined. Add a sorry. Looking back through all the mails it turns out this one wasn't approved yet. Ping? Bernd

Re: RFC: Building a minimal libgfortran for nvptx

On 11/04/2014 04:41 PM, Steve Kargl wrote: It is unclear to me from reading the diff whether this patch cause gfortran on ptx to knowingly violate the fortran standard. If the answer is yes, this patch causes gfortran on ptx to violate the standard, then the patch is IMHO unacceptable. I don't

<    10   11   12   13   14   15   16   17   18   19   >