This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: revised patch committed.


Amir Gonnen wrote:
> Ok, I accept the fact I'm on my own here :) at least regarding
> zero_extract on set destination.
> Let me try and revive this feature so that if any port in the future
> use it, it would still work.
>
> So dse does not handle lhs zero_extract, but it's still possible to
> work around the problem by treating such zero_extract as wild read in
> record_store in
> dse.c:
>
> --- dse.c
> +++ dse.c
> @@ -1301,6 +1301,16 @@
>      return 0;
>
>    mem = SET_DEST (body);
> +
> +
> +  /* bail out in case of ZERO_EXTRACT */
> +  if (GET_CODE(mem) == ZERO_EXTRACT)
> +  {
> +	add_wild_read (bb_info);
> +	insn_info->cannot_delete = true;
> +	return 0;
> +  }
> +
>
>    /* If this is not used, then this cannot be used to keep the insn
>       from being deleted.  On the other hand, it does provide something
>
> What do you think?
>   

i think that something like that should work.

kenny
>
> On Thu, Nov 5, 2009 at 6:50 PM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>   
>> The main reason that this was missed was that there are no public,
>> active ports that actually do this.  I accepted the patch on Ian
>> Taylor's (iant) advice because he said that it was legal as long as the
>> mem was a single byte.   Iant claimed that the last machine that could
>> do this kind of thing was the 68k but in his comments he did not
>> actually say if the gcc port actually did it.   Thus, you are really on
>> your own as to finding out how much else is broken to support this feature.
>>
>> When we test new passes, and I admit to being the person who wrote much
>> of dse, we test them on the active ports and we fix bugs against those
>> ports.   But a project like gcc is really a use it or loose it kind of
>> system.   The features that are exercised on the public active ports
>> work, and the features that are not exercised tend to rot, generally
>> until someone adds a new port that utilizes the feature.
>>
>> I think that the policy is that we accept patches from private ports as
>> long as they are fix problems with things that are supposed to work.
>> Certainly no one has pushed back on me for accepting your first patch.
>>
>> Kenny
>>
>>     


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]