Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
R
riscv-gcc-1
Overview
Overview
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
lvzhengyang
riscv-gcc-1
Commits
7467c975
Commit
7467c975
authored
Nov 11, 1999
by
Joern Rennecke
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Removed obsolete comment.
From-SVN: r30488
parent
665853dc
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
0 additions
and
8 deletions
+0
-8
gcc/reload.c
+0
-8
No files found.
gcc/reload.c
View file @
7467c975
...
...
@@ -4699,14 +4699,6 @@ find_reloads_address (mode, memrefloc, ad, loc, opnum, type, ind_levels, insn)
that the index needs a reload and find_reloads_address_1 will take care
of it.
There is still a case when we might generate an extra reload,
however. In certain cases eliminate_regs will return a MEM for a REG
(see the code there for details). In those cases, memory_address_p
applied to our address will return 0 so we will think that our offset
must be too large. But it might indeed be valid and the only problem
is that a MEM is present where a REG should be. This case should be
very rare and there doesn't seem to be any way to avoid it.
If we decide to do something here, it must be that
`double_reg_address_ok' is true and that this address rtl was made by
eliminate_regs. We generate a reload of the fp/sp/ap + constant and
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment