(Jakub Cc'd because of code he added for PR23567).
On 10/27/2015 11:35 PM, Abe wrote:
Thanks for all your feedback. I have integrated as much of it as I
could in the available time.
Unfortunately not all of it - I still think we need to have a better
strategy of selecting a scratchpad than a
On Tue, Oct 20, 2015 at 7:43 AM, Jeff Law wrote:
> On 10/14/2015 01:15 PM, Bernd Schmidt wrote:
>>
>> On 10/14/2015 07:43 PM, Jeff Law wrote:
>>>
>>> Obviously some pessimization relative to current code is necessary to
>>> fix some of the problems WRT thread safety and avoiding things like
>>> in
On 10/14/2015 01:15 PM, Bernd Schmidt wrote:
On 10/14/2015 07:43 PM, Jeff Law wrote:
Obviously some pessimization relative to current code is necessary to
fix some of the problems WRT thread safety and avoiding things like
introducing faults in code which did not previously fault.
Huh? This pa
On Wed, Oct 14, 2015 at 9:15 PM, Bernd Schmidt wrote:
> On 10/14/2015 07:43 PM, Jeff Law wrote:
>>
>> Obviously some pessimization relative to current code is necessary to
>> fix some of the problems WRT thread safety and avoiding things like
>> introducing faults in code which did not previously
On 10/14/2015 07:43 PM, Jeff Law wrote:
Obviously some pessimization relative to current code is necessary to
fix some of the problems WRT thread safety and avoiding things like
introducing faults in code which did not previously fault.
Huh? This patch is purely an (attempt at) optimization, no
On 10/14/2015 02:28 AM, Eric Botcazou wrote:
If you're using one of the switches that checks for stack overflow at the
start of the function, you certainly don't want to do any such stores.
There is a protection area for -fstack-check (STACK_CHECK_PROTECT bytes) so
you can do stores just below
On 10/13/2015 02:16 PM, Bernd Schmidt wrote:
_Potentially_ so, yes. However, GCC is free to put the allocation into
an otherwise-unused part of the stack frame.
Well, I looked at code generation changes, and it usually seems to come
with an increase in stack frame size - sometimes causing extr
> If you're using one of the switches that checks for stack overflow at the
> start of the function, you certainly don't want to do any such stores.
There is a protection area for -fstack-check (STACK_CHECK_PROTECT bytes) so
you can do stores just below the stack pointer as far as it's concerned.
On 10/14/2015 12:05 PM, Richard Henderson wrote:
If you're using one of the switches that checks for stack overflow at the start
of the function, you certainly don't want to do any such stores.
Oh, and for a given target the kernel may consider any write to the stack vma
below the stack pointe
On 10/09/2015 12:23 AM, Bernd Schmidt wrote:
On 10/08/2015 01:29 AM, Abe wrote:
Attached please find my revised patch to the RTL if converter. This
patch enables the
if-conversion of half-hammocks with a store in them that the internal
GCC machinery
otherwise considers too hazardous to if-conve
_Potentially_ so, yes. However, GCC is free to put the allocation into
an otherwise-unused part of the stack frame.
Well, I looked at code generation changes, and it usually seems to come
with an increase in stack frame size - sometimes causing extra
instructions to be emitted.
However, wh
On 10/08/2015 01:29 AM, Abe wrote:
Attached please find my revised patch to the RTL if converter. This
patch enables the
if-conversion of half-hammocks with a store in them that the internal
GCC machinery
otherwise considers too hazardous to if-convert. This is made safe by
using the
"scratchpa
+ /* We must copy the insns between the start of the THEN block
+ and the set of 'a', if they exist, since they may be needed
+ for the converted code as well, but we must not copy a
+ start-of-BB note if one is present, nor debug "insn"s. */
+
+ for (rtx_insn* insn = BB_HEAD (then_bb); ins
Abe,
please avoid comments that are not needed.
+ /* We must copy the insns between the start of the THEN block
+ and the set of 'a', if they exist, since they may be needed
+ for the converted code as well, but we must not copy a
+ start-of-BB note if one is present, nor debug "insn"s. */
Hi Abe,
could you please avoid double negations, and
please use early returns rather than huge right indentations:
+ if (! not_a_scratchpad_candidate)
+ {
+if (MEM_SIZE_KNOWN_P (orig_x))
+{
+ const size_t size_of_MEM = MEM_SIZE (orig_x);
+
+ if (size_of_MEM <= SCRATCHPAD_MAX_S
15 matches
Mail list logo
