Re: MSP430 in gcc4.9 ... enable interrupts?
On 14/02/14 20:17, DJ Delorie wrote:
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline assembler in a common
header file:
static inline __attribute__((always_inline))
void __nop()
{
asm volatile ("NOP");
}
static inline __attribute__((always_inline))
void __eint()
{
asm volatile ("EINT");
}
Or more simply:
#define __eint() asm("EINT")
#define __nop() asm("NOP")
For opcodes with parameters, you use a more complex form of inline
assembler:
static inline __attribute__((always_inline))
void BIC_SR(const int x)
{
asm volatile ("BIC.W %0,R2" :: "i" (x));
}
I presume these will be part of the headers for the library distributed
for msp430 gcc by TI/Redhat? (I know that's a bit off-topic for the gcc
list, but it is relevant to msp430 gcc users who don't want to have to
learn inline assembly.) I certainly think that's the right way to
handle this sort of thing - if it can be just as efficiently put in
headers using inline assembly, then maintenance is easier than putting
it into gcc itself.
When you say that the interrupt control in the compiler is for function
attributes, is that for the "critical" attribute that exists in the old
msp430 port (which disables interrupts for the duration of the
function)? I don't see it mentioned in the current gcc documentation,
but I haven't tried the code itself. It was certainly a nice idea - and
one that I would love to see supported on a range of gcc ports rather
than just the msp430.
David
Re: Vectorizer Pragmas
Renato Golin wrote: On 15 February 2014 19:26, Jakub Jelinek wrote: GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one can be used without rest of OpenMP by using -fopenmp-simd switch. Does the simd/omp have control over the tree vectorizer? Or are they just flags for the omp implementation? As '#pragma omp simd' doesn't generate any threads and doesn't call the OpenMP run-time library (libgomp), I would claim that it only controls the tree vectorizer. (Hence, -fopenmp-simd was added as it permits this control without enabling thread parallelization or dependence on libgomp or libpthread.) Compiler vendors (and users) have different ideas whether the SIMD pragmas should give the compiler only a hint or completely override the compiler's heuristics. In case of the Intel compiler, the user rules; in case of GCC, it only influences the heuristics unless one passes explicitly -fsimd-cost-model=unlimited (cf. also -Wopenmp-simd). [Remark regarding '#pragma simd': I believe that pragma is only active with -fcilkplus.] I don't see why we would need more ways to do the same thing. Me neither! That's what I'm trying to avoid. Do you guys use those pragmas for everything related to the vectorizer? I found that the Intel pragmas (not just simd and omp) are pretty good fit to most of our needed functionality. Does GCC use Intel pragmas to control the vectorizer? Would be good to know how you guys did it, so that we can follow the same pattern. As written by Jakub, only OpenMP's SIMD (requires: -fopenmp or -fopenmp-simd), Cilk plus's SIMD (-fcilkplus) and '#pragma gcc ivdep" (always enabled) are supported. As a user, I found Intel's pragmas interesting, but at the end regarded OpenMP's SIMD directives/pragmas as sufficient. Can GCC vectorize lexical blocks as well? Or just loops? According to http://gcc.gnu.org/projects/tree-ssa/vectorization.html, basic-block vectorization (SLP) support exists since 2009. Tobias
Re: Vectorizer Pragmas
On 16 February 2014 17:23, Tobias Burnus wrote: > As '#pragma omp simd' doesn't generate any threads and doesn't call the > OpenMP run-time library (libgomp), I would claim that it only controls the > tree vectorizer. (Hence, -fopenmp-simd was added as it permits this control > without enabling thread parallelization or dependence on libgomp or > libpthread.) Right, this is a bit confusing, but should suffice for out purposes, which are very similar to GCC's. > Compiler vendors (and users) have different ideas whether the SIMD pragmas > should give the compiler only a hint or completely override the compiler's > heuristics. In case of the Intel compiler, the user rules; in case of GCC, > it only influences the heuristics unless one passes explicitly > -fsimd-cost-model=unlimited (cf. also -Wopenmp-simd). We prefer to be on the safe side, too. We're adding a warning callback mechanism to warn about possible dangerous situations (debug messages already do that), possibly with the same idea as -Wopenmp-simd. But the intent is to not vectorize if we're sure it'll break things. Only on doubt we'll trust the pragmas/flags. The flag -fsimd-cost-model=unlimited might be a bit too heavy on other loops, and is the kind of think that I'd rather have as a pragma or not at all. > As a user, I found Intel's pragmas interesting, but at the end regarded > OpenMP's SIMD directives/pragmas as sufficient. That was the kind of user experience that I was looking for, thanks! > According to http://gcc.gnu.org/projects/tree-ssa/vectorization.html, > basic-block vectorization (SLP) support exists since 2009. Would it be desirable to use some pragmas to control lexical blocks, too? I'm not sure omp/cilk pragmas apply to lexical blocks... cheers, --renato
gcc-4.9-20140216 is now available
Snapshot gcc-4.9-20140216 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140216/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 207810 You'll find: gcc-4.9-20140216.tar.bz2 Complete GCC MD5=13a293d2679450709c160798cb454fc8 SHA1=be5137a796153fd7e31694148c61ce54b787220c Diffs from 4.9-20140209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.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: Vectorizer Pragmas
On 2/16/2014 2:05 PM, Renato Golin wrote: On 16 February 2014 17:23, Tobias Burnus wrote: Compiler vendors (and users) have different ideas whether the SIMD pragmas should give the compiler only a hint or completely override the compiler's heuristics. In case of the Intel compiler, the user rules; in case of GCC, it only influences the heuristics unless one passes explicitly -fsimd-cost-model=unlimited (cf. also -Wopenmp-simd). Yes, Intel's idea for simd directives is to vectorize without applying either cost models or concern about exceptions. I tried -fsimd-cost-model-unlimited on my tests; it made no difference. As a user, I found Intel's pragmas interesting, but at the end regarded OpenMP's SIMD directives/pragmas as sufficient. That was the kind of user experience that I was looking for, thanks! The alignment options for OpenMP 4 are limited, but OpenMP 4 also seems to prevent loop fusion, where alignment assertions may be more critical. In addition, Intel uses the older directives, which some marketer decided should be called Cilk(tm) Plus even when used in Fortran, to control whether streaming stores may be chosen in some situations. I think gcc supports those only by explicit intrinsics. I don't think many people want to use both OpenMP 4 and older Intel directives together. Several of these directives are still in an embryonic stage in both Intel and gnu compilers. -- Tim Prince
Re: TYPE_BINFO and canonical types at LTO
> On Fri, 14 Feb 2014, Jan Hubicka wrote:
>
> > > > This smells bad, since it is given a canonical type that is after the
> > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > completely
> > > > different class with completely different bases than the original.
> > > > Bases are
> > > > structuraly merged, too and may be exchanged for normal fields because
> > > > DECL_ARTIFICIAL (that separate bases and fields) does not seem to be
> > > > part of
> > > > the canonical type definition in LTO.
> > >
> > > Can you elaborate on that DECL_ARTIFICIAL thing? That is, what is broken
> > > by considering all fields during that merging?
> >
> > To make the code work with LTO, one can not merge
> > struct B {struct A a}
> > struct B: A {}
> >
> > these IMO differ only by DECL_ARTIFICIAL flag on the fields.
>
> "The code" == that BINFO walk? Is that because we walk a completely
Yes.
> unrelated BINFO chain? I'd say we should have merged its types
> so that difference shouldn't matter.
>
> Hopefully ;)
I am trying to make point that will matter. Here is completed testcase above:
struct A {int a;};
struct C:A {};
struct B {struct A a;};
struct C *p2;
struct B *p1;
int
t()
{
p1->a.a = 2;
return p2->a;
}
With patch I get:
Index: lto/lto.c
===
--- lto/lto.c (revision 20)
+++ lto/lto.c (working copy)
@@ -49,6 +49,8 @@ along with GCC; see the file COPYING3.
#include "data-streamer.h"
#include "context.h"
#include "pass_manager.h"
+#include "print-tree.h"
/* Number of parallel tasks to run, -1 if we want to use GNU Make jobserver.
*/
@@ -619,6 +621,15 @@ gimple_canonical_type_eq (const void *p1
{
const_tree t1 = (const_tree) p1;
const_tree t2 = (const_tree) p2;
+ if (gimple_canonical_types_compatible_p (CONST_CAST_TREE (t1),
+ CONST_CAST_TREE (t2))
+ && TREE_CODE (CONST_CAST_TREE (t1)) == RECORD_TYPE)
+ {
+ debug_tree (CONST_CAST_TREE (t1));
+ fprintf (stderr, "bases:%i\n", BINFO_BASE_BINFOS (TYPE_BINFO
(t1))->length());
+ debug_tree (CONST_CAST_TREE (t2));
+ fprintf (stderr, "bases:%i\n", BINFO_BASE_BINFOS (TYPE_BINFO
(t2))->length());
+ }
return gimple_canonical_types_compatible_p (CONST_CAST_TREE (t1),
CONST_CAST_TREE (t2));
}
constant 32>
unit size constant 4>
align 32 symtab 0 alias set -1 canonical type 0x76c52888
fields unit size
align 32 symtab 0 alias set -1 canonical type 0x76c52738 fields
context
chain >
nonlocal SI file t.C line 3 col 20 size
unit size
align 32 offset_align 128
offset
bit offset context
chain
nonlocal VOID file t.C line 3 col 10
align 1 context result >> context
pointer_to_this chain >
bases:0
constant 32>
unit size constant 4>
align 32 symtab 0 alias set -1 structural equality
fields unit size
align 32 symtab 0 alias set -1 canonical type 0x76c52738 fields
context
chain >
ignored SI file t.C line 2 col 8 size
unit size
align 32 offset_align 128
offset
bit offset context
chain
nonlocal VOID file t.C line 2 col 12
align 1 context result >> context
chain >
bases:1
So we prevail structure B with structure C. One has bases to walk other
doesn't.
If that BINFO walk in alias.c (on canonical types) did something useful, we
have a wrong code bug.
Yes, zero sized classes are those having no fields (but other stuff, type
decls, bases etc.)
Honza
GSoC project ideas
Hi, GCC has applied as a mentoring organization to GSoC 2014, and we need to update Project Ideas page: http://gcc.gnu.org/wiki/SummerOfCode . Ideas is where GSoC starts, and this is what captures attention and imagination of prospective students (and future developers!) of GCC. If you have an idea for a student project -- post it at http://gcc.gnu.org/wiki/SummerOfCode . If you can't easily edit the wiki directly, feel free to send your ideas to me directly or as a reply to this thread, I will add them to the wiki. You don't have to commit to be a mentor for an idea that you post. We will worry about finding mentors once a student expresses interest in a particular idea. You don't have to be an active GCC developer to post an idea. If you are an experienced GCC user and you wanted all your life a feature X in GCC -- post an idea about it. If you are a prospective GSoC student -- then we definitely want to hear your ideas. We need the ideas page all updated and ready by the end of February (couple of weeks left). Student applications period opens on March 10th, and keep in mind that students would need to meditate on the various projects/ideas/choices for a week or so. For GSoC 2014 timeline see https://www.google-melange.com/gsoc/events/google/gsoc2014 . Thank you, -- Maxim Kuvyrkov www.linaro.org
