2014-08-29 Wei Mi
* tree-cfg.c (struct locus_discrim_map): New field needs_increment.
(next_discriminator_for_locus): Increase discriminator only when
return_next or needs_increment are true.
(assign_discriminator): Add an actual for next_discriminator_for_locus.
> On Fri, Aug 29, 2014 at 10:11 AM, Cary Coutant wrote:
>>> To avoid the unused new discriminator value, I added a map
>>> "found_call_this_line" to track whether a call is the first call in a
>>> source line seen when assigning discriminators. For the first call in
>>> a source line, its discrimi
Thanks, that is ellegant. Will paste a new patch in this way soon.
Wei.
On Fri, Aug 29, 2014 at 10:11 AM, Cary Coutant wrote:
>> To avoid the unused new discriminator value, I added a map
>> "found_call_this_line" to track whether a call is the first call in a
>> source line seen when assigning
> To avoid the unused new discriminator value, I added a map
> "found_call_this_line" to track whether a call is the first call in a
> source line seen when assigning discriminators. For the first call in
> a source line, its discriminator is 0. For the following calls in the
> same source line, a
Hi Cary,
Is the new patch ok for google-4_9?
Thanks,
Wei.
On Sun, Aug 24, 2014 at 8:53 PM, Wei Mi wrote:
> To avoid the unused new discriminator value, I added a map
> "found_call_this_line" to track whether a call is the first call in a
> source line seen when assigning discriminators. For th
To avoid the unused new discriminator value, I added a map
"found_call_this_line" to track whether a call is the first call in a
source line seen when assigning discriminators. For the first call in
a source line, its discriminator is 0. For the following calls in the
same source line, a new discri
On Thu, Aug 7, 2014 at 2:40 PM, Xinliang David Li wrote:
> On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote:
>> No, it is not. This IR is dumped before early inline -- just after
>> pass_build_cfg. The line number of the deconstructor is marked
>> according to where its constructor is located,
>
> Th
On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote:
> No, it is not. This IR is dumped before early inline -- just after
> pass_build_cfg. The line number of the deconstructor is marked
> according to where its constructor is located,
The definition location or the invocation location?
David
> instea
No, it is not. This IR is dumped before early inline -- just after
pass_build_cfg. The line number of the deconstructor is marked
according to where its constructor is located, instead of where it is
inserted. This is also problematic.
Wei.
On Thu, Aug 7, 2014 at 12:11 PM, Xinliang David Li wrot
Yes, that is intentional. It is to avoid assiging a discriminator for
the first call in the group of calls with the same source lineno.
Starting from the second call in the group, it will get a different
discriminator with previous call in the same group.
Thanks,
Wei.
On Thu, Aug 7, 2014 at 12:17
> static int
> -next_discriminator_for_locus (location_t locus)
> +increase_discriminator_for_locus (location_t locus, bool return_next)
> {
>struct locus_discrim_map item;
>struct locus_discrim_map **slot;
> @@ -934,8 +936,10 @@ next_discriminator_for_locus (location_t
>(*slot)->
Is this
[1.cc : 179:64] Reader::~Reader (&version);
from an inline instance?
David
On Wed, Aug 6, 2014 at 10:18 AM, Wei Mi wrote:
> We saw bb like this in the IR dump after pass_build_cfg:
>
> :
> [1.cc : 205:45] D.332088 = table->_vptr.Table;
> [1.cc : 205:45] D.332134 = D.332088 + 104;
(Sorry if you received the mail twice because it was not plain text at
first and was rejected by @sourceware.org)
We saw bb like this in the IR dump after pass_build_cfg:
:
[1.cc : 205:45] D.332088 = table->_vptr.Table;
[1.cc : 205:45] D.332134 = D.332088 + 104;
[1.cc : 205:45] D.332135 =
13 matches
Mail list logo
