On 21/07/2014 12:25, Roman Gareev wrote:
I've asked the community about this.
The patch below contains the FIXME.
LGTM. Feel free to commit.
Thanks,
Tobias
I've asked the community about this.
The patch below contains the FIXME.
--
Cheers, Roman Gareev.
2014-07-12 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
Add inclusion of gimple-ssa.h, tree-into-ssa.h.
(ivs_params_clear):
On 21/07/2014 10:25, Roman Gareev wrote:
Maybe we should temporary postpone this and add a FIXME that says:
“We should remove iv_map.create (loop->num + 1), if it is possible.”
What do you think about this?
Fine with me. Please post a question on gcc devel to see if someone can
explain us t
Maybe we should temporary postpone this and add a FIXME that says:
“We should remove iv_map.create (loop->num + 1), if it is possible.”
What do you think about this?
--
Cheers, Roman Gareev.
> One of these two seems redundant.
I get the following error without “iv_map.create (loop->num + 1);”:
"/home/roman/sec_trunk/gcc/gcc/vec.h:1184:39: error: ‘iv_map’ may be
used uninitialized in this function [-Werror=maybe-uninitialized] {
return m_vec ? m_vec->length () : 0; }"
>Can you explai
One last question:
On 18/07/2014 12:28, Roman Gareev wrote:
+ iv_map.create (loop->num + 1);
+ iv_map.safe_grow_cleared (loop->num + 1);
One of these two seems redundant.
Cheers,
Tobias
> Can you explain why all functions would need to be rewritten? I proposed
> this function as an easier way to NULL initialize the vector and did not
> expect any rewrite to be necessary.
>
> If there is no such thing, please just add a comment that your loop NULL
> initializes the vector. We can l
On 17/07/2014 16:08, Roman Gareev wrote:
I see. Could you use vec_safe_grow_cleared(iv_map, loop_num) instead?
>This shows probably better that you zero initialize the vector.
If I am not mistaken, vec_safe_grow_cleared has the following declaration:
vec_safe_grow_cleared (vec *&v, unsigned len
> I see. Could you use vec_safe_grow_cleared(iv_map, loop_num) instead?
> This shows probably better that you zero initialize the vector.
If I am not mistaken, vec_safe_grow_cleared has the following declaration:
vec_safe_grow_cleared (vec *&v, unsigned len CXX_MEM_STAT_INFO)
Should we rewrite a
On 15/07/2014 16:59, Roman Gareev wrote:
>> >This is a pure style change which seems unrelated. Also, is the
original
>line really too long? I may have miscounted, but it seems to fit
>exactly.
If I am not mistaken, lines should be limited to 80 characters,
according to conventions, which are m
> No, no idea. To my understanding the entry block should not even appear
> within a scop (see build_scops, where we only start detecting scops at
> the successor of the entry_block). Maybe we replace this with an assert
> to get a good error message in case I have missed something.
Yes, I think t
On 12/07/2014 14:18, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_user.
I think that it would be better to add motivation for the following
line from the original source:
if (GBB_BB (gbb) == ENTRY_BLOCK_PTR_FOR_FN (cfun))
{
isl_
12 matches
Mail list logo
