Gabriel Charette a écrit:
> From what I understand, the source_locations allocated for
> everything in a given set of headers (from the LC_ENTER for the
> header in the line_table up to, and including everything in between,
> the corresponding LC_LEAVE) is dependent on only one thing; the
> value
I've been looking at SMS, and have a question about get_sched_window.
When there are previously-scheduled predessors, we use:
if (e->data_type == MEM_DEP)
end = MIN (end, SCHED_TIME (v_node) + ii - 1);
to get an upper bound on the scheduling window that is permitted
Richard Sandiford writes:
> I've been looking at SMS, and have a question about get_sched_window.
> When there are previously-scheduled predessors, we use:
>
> if (e->data_type == MEM_DEP)
> end = MIN (end, SCHED_TIME (v_node) + ii - 1);
>
> to get an upper bound on the s
Hello Richard,
> I ask because in the final range:
>
> start = early_start;
> end = MIN (end, early_start + ii);
> /* Schedule the node close to it's predecessors. */
> step = 1;
>
> END is an exclusive bound. It seems like we might be double-counting
here,
> and effectiv
I think I wasn't clear in the way I expressed my assumptions in my last email:
On Wed, Jul 27, 2011 at 1:11 AM, Dodji Seketeli wrote:
>
> Gabriel Charette a écrit:
>
> > From what I understand, the source_locations allocated for
> > everything in a given set of headers (from the LC_ENTER for the
Gabriel Charette a écrit:
> Actually from my understanding, highest_location is not equal to the
> last start_location, but to the last source_location returned by
> either linemap_line_start or linemap_positition_for_column (which is
> >>= to the start_location of the current line_map).
Right,
Hello!
Is there any scripts/tools that parse GCC dumps and report register
pressure in the dump - either overall, or in different parts of the
dump?
regards,
Sergos
>>
>> Hence, given that they only depend on start_location, I just have to
>> calculate an offset between the serialized start_location and the
>> start_location as it would be (highest_location + 1) in the C file
>> including the header, and offset all of the source_locations on each
>> token comi
On 07/27/2011 10:26 AM, Sergey Ostanevich wrote:
Hello!
Is there any scripts/tools that parse GCC dumps and report register
pressure in the dump - either overall, or in different parts of the
dump?
-fdump-rtl-ira creates an info dump of IRA. There is info about maximal
pressure for each regio
Gabriel Charette a écrit:
>>>
>>> Hence, given that they only depend on start_location, I just have to
>>> calculate an offset between the serialized start_location and the
>>> start_location as it would be (highest_location + 1) in the C file
>>> including the header, and offset all of the sourc
(sorry for replicated submissions, had to convert to plain text)
>2011/7/27 Revital1 Eres
>
>Hello Richard,
>
>
>> I ask because in the final range:
>>
>> start = early_start;
>> end = MIN (end, early_start + ii);
>> /* Schedule the node close to it's predecessors. */
>>
On Wed, Jul 13, 2011 at 6:22 AM, Ian Lance Taylor wrote:
> Igor Zamyatin writes:
>
>> As you may see pta_flags enum in i386.c is almost full. So there is a
>> risk of overflow in quite near future. Comment in source code advises
>> "widen struct pta flags" which is now defined as unsigned. But it
On Wed, Jul 27, 2011 at 6:42 PM, H.J. Lu wrote:
>>> As you may see pta_flags enum in i386.c is almost full. So there is a
>>> risk of overflow in quite near future. Comment in source code advises
>>> "widen struct pta flags" which is now defined as unsigned. But it
>>> looks not optimal.
>>>
>>>
On Wed, Jul 27, 2011 at 10:00 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 6:42 PM, H.J. Lu wrote:
>
As you may see pta_flags enum in i386.c is almost full. So there is a
risk of overflow in quite near future. Comment in source code advises
"widen struct pta flags" which is now
Le 26 juil. 2011 à 16:45, Yvan ROUX a écrit :
> Hi,
>
> Romain is doing an internship at STMicroelectronics on GCC plugins, and
> as his mentor, I confirm and/or inform you that he is covered by the
> copyright assignement RT 211150 between ST and FSF.
>
> Regards.
>
> --
> Yvan ROUX
> STMicro
> [romain.geiss...@gmail.com - Wed Jul 27 14:05:48 2011]:
>
> Le 26 juil. 2011 à 16:45, Yvan ROUX a écrit :
> > Hi,
> >
> > Romain is doing an internship at STMicroelectronics on GCC plugins, and
> > as his mentor, I confirm and/or inform you that he is covered by the
> > copyright assignement RT
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
CPython interpreter within GCC, allowing you to write new compiler
warnings in Python, generate code visualizations, etc.
Tarball releases are available at:
https://fedorahosted.org/releases/g/c/gcc-python-plugin/
Prebuilt-docum
On Wed, 27 Jul 2011, H.J. Lu wrote:
> ; Maximum number of mask bits in a variable.
> MaxMaskBits
> ix86_isa_flags = 64
>
> It mark ix86_isa_flags as 64bit. Any comments?
The patch won't work as is. set_option, for example, casts a pointer to
(int *), and stores a mask that came from option->v
On Wed, Jul 27, 2011 at 2:23 PM, Joseph S. Myers
wrote:
> On Wed, 27 Jul 2011, H.J. Lu wrote:
>
>> ; Maximum number of mask bits in a variable.
>> MaxMaskBits
>> ix86_isa_flags = 64
>>
>> It mark ix86_isa_flags as 64bit. Any comments?
>
> The patch won't work as is. set_option, for example, cast
Consider this bit of code:
extern double a[20];
double test1 (int n)
{
double accum = 0.0;
int i;
for (i=0; imipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1
-S abstest.c
With a GCC 4.6 compiler, this produces:
...
.L3:
mtc1$3,$f2
ldc1$f0
20 matches
Mail list logo
