Konstantin Vladimirov schrieb:
Hi,
This problem is backend independent, so I build reproduction in x86
backend. Consider code:
int func(int x);
int test(int x, int *data)
{
int retval;
register int *buffer asm ("eax");
buffer = data;
retval = func(x);
__asm__ __volatile__ (".interna
Joseph S. Myers wrote:
> On Fri, 20 Jan 2012, Georg-Johann Lay wrote:
>
>> Hi.
>>
>> avr-gcc implements a 24-bit scalar integer types __int24 and __uint24 in
>> avr.c:TARGET_INIT_BUILTINS like so:
>>
>> tree int24_type = make_signed_type (GET_MODE
Joseph S. Myers wrote:
> On Wed, 25 Jan 2012, Georg-Johann Lay wrote:
>
>> You mean that thread?
>> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00064.html
>> and
>> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00079.html
>
> Yes, the whole thread (with parti
Richard Henderson schrieb:
On 01/21/2012 01:48 AM, Georg-Johann Lay wrote:
FRACTIONAL_INT_MODE (PSI, 24, 3);
Unrelated to everything else, I'm not sure you want a *fractional* mode.
You're using all bits of the 3 bytes of storage. Fractional modes are
those where there are unus
Alan Lehotsky schrieb:
I'm working on a port to a Harvard architecture where the data memory
addresses are only 14 bits wide (e.g. 16kb) and the instruction
address space is 21 bits wide.
I do not want to define Pmode as PSImode; the machine has separate
address registers for data memory AND wit
Hi,
may I propose to change this message to a more user-friendly one?
In most cases, the message is triggered by a typo like here:
Int foo (void)
{
return 1;
}
A message like
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
is just pain to the eyes, and apart from tha
This patchlet fixes length computation of "std %0,%1" and "st %0,%1" that
reported 2 instead of 1. The reason is that the insn length was accumulated and
added to the length of 1 already set in the caller.
These length are unconditionally set to 1 now because there is no code emit
before these ins
Miles Bader wrote:
> Chris Lattner writes:
>>> Int foo (void) { return 1; }
>>>
>>> A message like
>>> error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
>>>
>>> is just pain to the eyes, and apart from that it is not more helpful
>>> than a simple "syntax error before 'foo':
>>
Zoltán Kócsi schrieb:
paul_kon...@dell.com> wrote:
I would prefer this to generate a warning. The C language standard change
you refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work
one way or the oth
Hi,
./gcc/config/avr/avr.md
defines andsi3 as follows:
(define_insn "andsi3"
[(set (match_operand:SI 0 "register_operand" "=r,d")
(and:SI (match_operand:SI 1 "register_operand" "%0,0")
(match_operand:SI 2 "nonmemory_operand" "r,i")))]
""
"*{
if (which_alternative
Hi,
I am trying to write some simple builtin functions for target avr.
The buitins themselves are no proplem. The expansion works as intended.
What is unacceptable is a code bloat of +100% ... +150% during the RTL
passes.
So can anyone assist me in writing down RTL that will yield best/accepta
Weddington, Eric schrieb:
Hi,
I am trying to write some simple builtin functions for target avr.
Hi Georg-Johann,
Anatoly Sokolov and I already have a patch to add builtin function capabilities
for the AVR. Could you send us your patches?
Hi Eric,
I just gave the builtin approch for pg
Joseph S. Myers schrieb:
On Wed, 21 Jan 2009, Georg-Johann Lay wrote:
Up to now, LPM is not implemented in the compiler because GCC does not
allow to add new target specific qualifiers like "flash".
Note that work on ISO TR 18037 named address spaces is underway for GCC
4.5 (cu
Weddington, Eric schrieb:
> Anatoly Sokolov and I already have a patch to add builtin function
capabilities for the AVR. Could you send us your patches?
The patch is contained in my top post
http://gcc.gnu.org/ml/gcc/2009-01/msg00309.html
Here a verbatim copy, so it is easier to discuss wha
Hi,
in machine description expanders the functions copy_to_mode_reg and and
force_reg from explow.c can be used to ensure that an operand lives in a
register.
But what function should be used?
What are the differences? The only difference I can depict from the
comment is that an operand retu
Georg-Johann Lay schrieb:
Hi,
in machine description expanders the functions copy_to_mode_reg and and
force_reg from explow.c can be used to ensure that an operand lives in a
register.
But what function should be used?
By the way: Are there better places to ask such questions like in gcc
Hi, I already submitted some patches for the avr backend and have still
a bunch of ideas for implrovements.
However, I am still unsure about insn constraints and what they must
look like to work in any situation, and I want to learn more about that
subject before commnuity tars and feathers me
In order to improve bit manipulations for avr, patterns like the following can
be used:
+;; [0].log[4] |= [2].log[4]+[3]
+(define_insn "*iorqi2_shiftrt_bit"
+ [(set (match_operand:QI 0 "register_operand" "=d,r")
+(ior:QI (and:QI (match_operator:QI 1 "shiftrt_operator"
+
Georg-Johann Lay schrieb:
source, or if they are dead and just pollute backend. Introducing extzv
and insv could bring some effort (I didn't try what impact they have)
Sorry for the typo. Please replace "effort" with "improvement" or "relief".
Stelian Pop schrieb:
Hi,
I need to use a scratch register in the "jump" pattern and I can't
figure out how to do it properly.
My problem is that the microcontroller I'm porting gcc onto does not
permit "far" jumps, those must be done using an indirect adressing.
So I wrote this:
-
Stelian Pop schrieb:
On Tue, Mar 10, 2009 at 10:18:10PM +0100, Georg-Johann Lay wrote:
Note that no one is generating an insn that looks like "*jump". Maybe
insn combine and peep2 would try to build such a pattern, but that is
not what helpd you out here. Write the expander as p
Jamie Prescott schrieb:
Thank you Andrew, I wasn't aware of that. Will be going that way.
Just out of curiosity, was there something flawed in the way I took before?
Meaning, could have been done that way, but my code was wrong somewhere?
- Jamie
- Original Message
From: Andrew Pins
Jamie Prescott schrieb:
On Mon, May 11, 2009 at 4:45 PM, Jamie Prescott wrote:
Hi!
I wanted to add finer (one per) register subclasses, so that I can more
finely
control
the register placement inside the inline assembly.
You don't need that.
You can just use asm("registername") on v
Michael Hope schrieb:
The problem is when I have to clobber ACC such as when moving between
registers. The output should be:
LOADACC, R10; STOREACC, R11 (equivalent to ACC = R10; R11 = ACC)
I've tried a parallel clobber like:
(define_insn "movsi"
[(set (match_operand:SI 0 "nonimmediate_oper
Jamie Prescott schrieb:
Is the implementation I posted the only one, or there are shorter/better ones?
You could use insn attribute to express insns' effects on cc_status.
Have a look at the avr backend.
Georg-Johann
Jamie Prescott schrieb:
Is there a reason why something like this would not work?
(define_insn "addsi3_nc"
[(set (match_operand:SI 0 "fullreg_operand" "=r")
(plus:SI (match_operand:SI 1 "fullreg_operand" "r")
(match_operand:SI 2 "fullreg_or_imm_operand" "rn")))]
""
Jamie Prescott schrieb:
Thanks for the explanation. I somehow thought that every insn spit out by a
define_insn was automatically turned into a parallel.
That's true, the template of a define_insn is automatically wrapped up in a
PARALLEL. But your addsi3 is a define_expand and this works di
Weddington, Eric schrieb:
Hi All,
This may be a dumb question, but I'm having difficulty finding the answer to
this.
I'm working on a back-end and I have a function being called for the
FUNCTION_ARG macro, and in that function I need to find out the attributes of
the called function as this
Hi,
I'd like to support sibling calls for a target where function args can
be passed in call-saved registers, namely AVR.
The trouble is this: If a callee gets some arguments passed on the stack
or in call-saved regs, the callee is not ok for a sibling call. That's
because sibcall_epilogue e
Ian Lance Taylor schrieb:
Georg-Johann Lay writes:
The trouble is this: If a callee gets some arguments passed on the
stack or in call-saved regs, the callee is not ok for a sibling
call. That's because sibcall_epilogue executes before sibcall insns.
I'm having trouble with your t
Dave Korn schrieb:
Georg-Johann Lay wrote:
The trouble is this: If a callee gets some arguments passed on the stack
or in call-saved regs, the callee is not ok for a sibling call. That's
because sibcall_epilogue executes before sibcall insns.
All this information is pretty easy availab
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
I'd like to support sibling calls for a target where function args can
be passed in call-saved registers, namely AVR.
The s390 back-end already has the very same issue. You may want to have
a look at config/s390
cured because avr-libc made some implication on how gcc will
inline functions, so that an indirect access finally collapses to a
direct one. As I am sill using avr-gcc-3.4.6 which runs pretty smooth
and the compiler has hot the knowledge, I didn't think about it
further) accessing eeprom is not as easy as accessing flash. Perhaps
some new eeprom- or SFR-relocs could help to shift the information
from avr-gcc to avr-binutils.
--
Georg Johann Lay
Is there a policy/agreement on how to deal with vendor specific dwarf?
Suppose an backend implements some unspec_volatile (UV) and has a
destinct understanding of what it should be.
If other parts of the compiler don't know exactly what to do, it's a
potential source of trouble.
- "May I schedule across the unspec_volatile (UV) or not?"
- "May I move the UV from
Implementation as outlined as in
http://gcc.gnu.org/ml/gcc/2010-11/msg00222.html
Ian Lance Taylor schrieb:
Georg Johann Lay writes:
Suppose an backend implements some unspec_volatile (UV) and has a
destinct understanding of what it should be.
If other parts of the compiler don't know exactly what to do, it's a
potential source of trouble.
- "May I sche
Hook in and discuss
http://gcc.gnu.org/ml/gcc/2010-11/msg00232.html
Hi, I just observed that links like
https://gcc.gnu.org/install/configure.html
ceased to work. Presumably this is to sphinx stuff, but it would be
great if not hundreds of links across the web to GCC pages like the
above would be 404.
I know that the new link is
https://gcc.gnu.org/install
Am 10.11.22 um 16:05 schrieb Martin Liška:
On 11/10/22 15:45, Georg-Johann Lay wrote:
Hi, I just observed that links like
https://gcc.gnu.org/install/configure.html
ceased to work. Presumably this is to sphinx stuff, but it would be
great if not hundreds of links across the web to GCC
Am 10.11.22 um 16:25 schrieb Jonathan Wakely:
On Thu, 10 Nov 2022 at 15:23, Jonathan Wakely wrote:
On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay wrote:
Am 10.11.22 um 16:05 schrieb Martin Liška:
On 11/10/22 15:45, Georg-Johann Lay wrote:
Hi, I just observed that links like
https
Am 11.11.22 um 09:48 schrieb Martin Liška:
On 11/10/22 18:01, Jonathan Wakely wrote:
Maybe just "docs" or "trunkdocs" or "latestdocs" instead of
"onlinedocs-new", since that is (1) very long, and (2) will look silly
in ten years when it's not new and we need to add
onlinedocs-even-newer 😉
I
The following code throws a warning which I do not understand.
Purpose is to save and restore SREG, which is a special function
register (SFR) defined by its hardware address as:
#define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__))
which is the common C idiom to define such an SFR.
Am 23.11.22 um 18:18 schrieb Andrew Pinski:
On Wed, Nov 23, 2022 at 9:15 AM Georg-Johann Lay wrote:
The following code throws a warning which I do not understand.
Purpose is to save and restore SREG, which is a special function
register (SFR) defined by its hardware address as:
#define
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 120ul)
PORT |= 1;
}
When I compile it with
$
Am 09.12.22 um 22:14 schrieb Vladimir Makarov:
On 2022-12-09 14:23, Georg-Johann Lay wrote:
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
I am sorry, I feel your frustration. I was not aware of this PR.
Unfortunately, the PR was marked as P4 and I
This error pops up in the testsuite for avr.
As far as I understand, this is due to target-specific optimization like
in avr-common.cc:
{ OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mgas_isr_prologues, NULL, 1 },
{ OPT_LEVELS_1_PLUS, OPT_mmain_is_OS_task, NULL, 1 },
// Stick to the "old" plac
PR target/104327 not only affects s390 but also avr:
The avr backend pre-sets some options depending on optimization level.
The inliner then thinks that always_inline functions are not eligible
for inlining and terminates with an error.
Proposing the following patch that implements TARGET_CAN_INL
For some time now I am staring at the following test case and what
combine does with it:
typedef struct
{
unsigned b0 : 1;
unsigned b1 : 1;
unsigned b2 : 1;
unsigned b3 : 1;
unsigned b4 : 1;
unsigned b5 : 1;
unsigned b6 : 1;
unsigned b7 : 1;
} b_t;
Prior to combin
Am 24.05.23 um 11:38 schrieb Richard Biener:
On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote:
PR target/104327 not only affects s390 but also avr:
The avr backend pre-sets some options depending on optimization level.
The inliner then thinks that always_inline functions are not
Am 24.05.23 um 11:28 schrieb Richard Biener:
On Tue, May 23, 2023 at 1:25 PM Georg-Johann Lay wrote:
This error pops up in the testsuite for avr.
As far as I understand, this is due to target-specific optimization like
in avr-common.cc:
{ OPT_LEVELS_1_PLUS_NOT_DEBUG
Am 25.05.23 um 08:35 schrieb Richard Biener:
On Wed, May 24, 2023 at 5:44 PM Georg-Johann Lay wrote:
Am 24.05.23 um 11:38 schrieb Richard Biener:
On Tue, May 23, 2023 at 2:56 PM Georg-Johann Lay wrote:
PR target/104327 not only affects s390 but also avr:
The avr backend pre-sets some
Am 24.05.23 um 14:31 schrieb Richard Earnshaw (lists):
On 23/05/2023 19:41, Georg-Johann Lay wrote:
For some time now I am staring at the following test case and what
combine does with it:
typedef struct
{
unsigned b0 : 1;
unsigned b1 : 1;
unsigned b2 : 1;
unsigned b3
Am 17.07.23 um 13:33 schrieb SenthilKumar.Selvaraj--- via Gcc:
Hi,
The avr target has a bunch of patterns that directly set hard regs at expand
time, like so
The correct approach would be to use usual predicates together with
constraints that describe the register instead of hard regs,
Am 28.07.23 um 07:04 schrieb senthilkumar.selva...@microchip.com:
On Thu, 2023-07-27 at 15:11 +0200, Georg-Johann Lay wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
Am 17.07.23 um 13:33 schrieb SenthilKumar.Selvaraj--- via Gcc:
Hi
Am 09.08.23 um 13:15 schrieb SenthilKumar.Selvaraj--- via Gcc:
[...]
I guess the condition exists to ensure sp_off is always correct? Considering
LRA already
handles post_dec of SP just fine, perhaps it can allow RTX like
(set (reg/f:HI 32 __SP_L__)
(plus:HI (reg/f:HI 32 __SP_L__
Am 15.08.23 um 14:06 schrieb Richard Biener via Gcc:
On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc wrote:
Also, on another backend I saw comments relating to libgcc (or newlib?)
not working that well on systems where int is 16bit. Is that still true,
and what is the best workaround?
You
Am 20.11.23 um 08:14 schrieb SenthilKumar.Selvaraj--- via Gcc:
On Thu, 2023-10-05 at 15:33 -0400, Vladimir Makarov wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
On 9/7/23 07:21, senthilkumar.selva...@microchip.com wrote:
Hi,
One more
The avr backend supports variable attributes like the following that
allow to define symbols:
__attribute__((address(1234))
char a_symbol;
would produce assembly
.global a_symbol
a_symbol = 1234
This works except for -fdata-sections -fno-common (PR112952), and I am
struggling to find a fix.
C
Just noticed that -ffold-mem-offsets is a target option, i.e. it is
shown with --help=target
> grep -A3 mem-off common.opt
ffold-mem-offsets
Target Bool Var(flag_fold_mem_offsets) Init(1)
Fold instructions calculating memory offsets to the memory access
instruction if possible.
Is that "Target
Am 15.01.24 um 13:20 schrieb Richard Biener:
On Mon, Jan 15, 2024 at 11:22 AM Georg-Johann Lay wrote:
Just noticed that -ffold-mem-offsets is a target option, i.e. it is
shown with --help=target
> grep -A3 mem-off common.opt
ffold-mem-offsets
Target Bool Var(flag_fold_mem_offsets) I
We have this (rare?) wrong code bug
https://gcc.gnu.org/PR101188
which Jeff fixed for v14:
https://gcc.gnu.org/r14-1738
The fix doesn't fit 100% for v13 but the PR has a backport for v13
in comment #16. Would be great if this could be part of v13.3,
but I don't have the resources to reg-test
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an
isinff() implementation that's written in asm (PR115307).
Johann
Am 31.05.24 um 15:56 schrieb Jonathan Wakely:
On Fri, 31 May 2024 at 14:52, Georg-Johann Lay wrote:
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an
isinff() implementation that's written in asm
Am 31.05.24 um 17:00 schrieb Paul Koning:
On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an isinff()
implementation that's written in asm
Am 31.05.24 um 19:32 schrieb Richard Biener:
Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
Am 31.05.24 um 17:00 schrieb Paul Koning:
On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
What's the recommended w
Am 31.05.24 um 22:12 schrieb Richard Biener:
Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay :
Am 31.05.24 um 19:32 schrieb Richard Biener:
Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
Am 31.05.24 um 17:00 schrieb
Am 08.06.24 um 11:32 schrieb Mikael Pettersson via Gcc:
On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote:
Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From
a quick search I see that the iq2000 and rx backends are rewriting some
PLUS expression addresses with insn s
Am 10.06.24 um 18:35 schrieb Paul Koning:
On Jun 10, 2024, at 11:48 AM, Georg-Johann Lay wrote:
Am 08.06.24 um 11:32 schrieb Mikael Pettersson via Gcc:
On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote:
Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From
a quick
Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
Hi all,
I'm trying to add an alternative to an existing insn foobar:
(define_insn "foobar"
[(set (match_operand ...)
(match_operand ...))]
""
"@
foo
bar
#")
Since the asm output depends on the op
Am 22.06.24 um 10:46 schrieb Stefan Schulze Frielinghaus:
On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
Hi all,
I'm trying to add an alternative to an existing insn foobar:
(define_insn "foobar&
Is it possible to specify a default value in
define_code_attr resp. define_mode_attr ?
I had a quick look at read-rtl, and it seem to be not the case.
Or am I missing something?
Johann
So I had that situation where in an insn attribute, providing
a block of code (rather than just an expression) would be
useful.
Expressions can provided by means of symbol_ref, like in
(set (attr "length")
(symbol_ref ("1 + GET_MODE_SIZE (mode)")))
However providing a block of code gives a
Am 15.07.24 um 19:53 schrieb Richard Sandiford:
Georg-Johann Lay writes:
In a test case I see insn combine trying to match such
expressions, which do not make any sense to me, like:
Trying 2 -> 7:
2: r45:HI=r48:HI
REG_DEAD r48:HI
7: {r47:HI=r45:HI|r46:PSI#0;clob
Am 13.07.24 um 13:44 schrieb Richard Sandiford:
Georg-Johann Lay writes:
So I had that situation where in an insn attribute, providing
a block of code (rather than just an expression) would be
useful.
Expressions can provided by means of symbol_ref, like in
(set (attr "l
Am 17.07.24 um 20:49 schrieb Richard Sandiford:
Georg-Johann Lay writes:
[...]
Am 13.07.24 um 13:44 schrieb Richard Sandiford:
It shouldn't be necessary to emit the enum tag these days. If removing
Hi Richard,
I am not familiar with the gensupport policies, which is the reason wh
You have already asked that question (and got an answer) in gcc-help@:
https://gcc.gnu.org/pipermail/gcc-help/2024-August/thread.html#143628
Johann
Am 08.08.24 um 03:54 schrieb Amit Hiremath:
Hello,
I want to add custom single precision floating point sine, cosine, exp
instructions to risc-v
Am 08.08.24 um 10:08 schrieb Amit Hiremath:
I know, I am looking for a solution without using __asm macro
I explained that, too. Did you even read my answer?
Johann
On Thu, Aug 8, 2024 at 1:20 PM Georg-Johann Lay
You have already asked that question (and got an answer) in gcc-help
I just noticed that one of my commits,
https://gcc.gnu.org/r15-2865
is missing from
https://gcc.gnu.org/pipermail/gcc-cvs/2024-August/date.html
Even though it has the tag "PR target/113934" the respective
PR didn't get a pointer to the commit:
https://gcc.gnu.org/PR113934
Did I do something
Am 12.08.24 um 19:45 schrieb Mark Wielaard:
Hi Johann,
On Sat, Aug 10, 2024 at 07:34:09PM +0200, Georg-Johann Lay wrote:
I just noticed that one of my commits,
https://gcc.gnu.org/r15-2865
is missing from
https://gcc.gnu.org/pipermail/gcc-cvs/2024-August/date.html
Even though it has the
Hi, in an RTL optimization pass I would like to
perform a transformation like from old code:
[bb 1]
if (condA);; insn1
goto label_1;
[bb 2]
if (cond_B) ;; insn2
goto label_2;
to new code:
[bb 1]
if (cond1) ;; branch1
goto label_2;
[bb 2]
if (cond2) ;;
Am 21.08.24 um 11:31 schrieb Richard Biener:
On Wed, Aug 21, 2024 at 11:19 AM Georg-Johann Lay wrote:
Hi, in an RTL optimization pass I would like to
perform a transformation like from old code:
[bb 1]
if (condA);; insn1
goto label_1;
[bb 2]
if (cond_B) ;; insn2
Trying to use the value-range interface and functions I am running
into that ICE when using invert().
From what the sources suggest, invert() computes the complement of
the current set (the union of finitely many intervals).
For example, when I have a range of [-128, -1] for int8_t, invert()
run
Am 03.09.24 um 18:12 schrieb Andrew MacLeod:
On 8/25/24 03:48, Richard Biener wrote:
On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote:
Trying to use the value-range interface and functions I am running
into that ICE when using invert().
From what the sources suggest, invert
While implementing PR56263 (Strict address-space checking for AVR), I
encountered the problem that pointer casts with address spaces are always
expanded as const_int 0.
The problem occurs if the attached patch that implements PR56263 and the
following code is compiled as
$ avr-gcc -Os flash-cast.
Richard Biener wrote:
> On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
> wrote:
>> On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay wrote:
>>> While implementing PR56263 (Strict address-space checking for AVR), I
>>> encountered the problem that pointer casts
Richard Biener wrote:
> On Fri, Mar 8, 2013 at 5:03 PM, Georg-Johann Lay wrote:
>> Richard Biener wrote:
>>> On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
>>> wrote:
>>>> On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay wrote:
>>>>> While i
Paulo Matos schrieb:
I am convinced that what I am about to ask is not possible but I
would like someone to confirm this.
Can I define in an insn a register constraint that depends on another
register value? So, for
(set (match_operand:SI 0 "register_operand" "r")
(match_operand:SI 1 "regi
Ondrej Bilka schrieb:
http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
This is wrong:
@@ -10834,7 +10834,7 @@ avr_convert_to_type (tree type, tree expr)
XOP[2] # Bytes to copy
Return TRUE if the expansion is accomplished.
- Return FALSE if the operand compination is not supported
Yury Gribov schrieb:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting point
Am 02/27/2014 06:03 PM, schrieb Richard Sandiford:
Yury Gribov writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
Am 02/27/2014 03:34 PM, schrieb Richard Biener:
I've been hacking on a prototype that generates matching and
simplification code from a meta-description. The goal is
to provide a single source of transforms currently spread
over the compiler, mostly fold-const.c, gimple-fold.c and
tree-ssa-forw
Am 03/25/2014 01:28 PM, schrieb Jeff Law:
On 03/25/14 06:23, Umesh Kalappa wrote:
Dear All,
The GCC source reference 4.8.1 will synthesized some of the double
word operations(SI mode) like add /sub in the below case from the word
size (HI) patterns,
(code snippet)
expand_binop_directly functi
This is a question on SUBREGs generated by lower-subreg.c and whether register
allocator is supposed to handle them efficiently.
Suppose the following small function compiled for AVR.
Remember AVR is 8-bit machine with int = HImode and UNITS_PER_WORD = 1.
int add (int val)
{
return val + 1;
}
Vladimir Makarov wrote:
> On 02/15/2012 09:21 AM, Georg-Johann Lay wrote:
>> This is a question on SUBREGs generated by lower-subreg.c and whether
>> register
>> allocator is supposed to handle them efficiently.
>>
>> Suppose the following small function compiled
I had a look into this again for the following small C program:
struct rgb { char r; };
char read_bug (const __flash struct rgb *s)
{
struct rgb t = *s;
return t.r;
}
char read_ok (const __flash struct rgb *s)
{
return s->r;
}
compiled as
> avr-gcc flash-move.c -S -Os -dp -fdump-
Suppose the following insn from avr.md:
(define_insn "xload__libgcc"
[(set (reg:MOVMODE 22)
(mem:MOVMODE (lo_sum:PSI (reg:QI 21)
(reg:HI REG_Z
(clobber (reg:QI 21))
(clobber (reg:HI REG_Z))]
"avr_xload_libgcc_p (mode)"
{
rtx x_bytes = G
Richard Henderson wrote:
> On 02/17/12 07:11, Georg-Johann Lay wrote:
>> ; (insn 13 12 8 (parallel [
>> ; (set (reg:SI 22 r22)
>> ; (mem:SI (lo_sum:PSI (reg:QI 21 r21)
>> ; (reg:HI 30 r30)) [0 S4 A8 AS7]))
>>
toplev.c emits __gnu_lto markers to assembler:
/* Emit LTO marker if LTO info has been previously emitted. This is
used by collect2 to determine whether an object file contains IL.
We used to emit an undefined reference here, but this produces
link errors if an object file with I
For the following small test case there is unbelievable code bloat from
lower-subreg.c
The code reads a 4-byte value from AVR's address spaces:
long readx (const __memx long *p)
{
return *p;
}
long read1 (const __flash1 long *p)
{
return *p;
}
Compiled with 4.8.0
$ avr-gcc flash.c -
201 - 300 of 366 matches
Mail list logo
