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: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers


On Feb  9, 2018, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Feb  9, 2018, Jeff Law <law@redhat.com> wrote:
>> On 02/08/2018 08:53 PM, Alan Modra wrote:
>>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
>>>> Here's what I checked in, right after the LVU patch.
>>>> 
>>>> [IEPM] Introduce inline entry point markers
>>> 
>>> One of these two patches breaks ppc64le bootstrap with the assembler
>>> complaining "Error: view number mismatch" when compiling
>>> libdecnumber.
>>> 
>> I've just passed along a similar failure (.i, .s and command line
>> options) to Alex for ppc64 (be) building glibc.

> Thanks.  So, I'm told there are more such issues, that non-asm insn
> length attrs can't be relied on at this time to be nonzero only when the
> actual length is not zero.

I wonder...  In the previously-posted patch, we still regard call insns
are advancing PC.  I think that's a safe assumption, but...  are there
any other kinds of patterns we could recognize that would certainly
generate an actual PC-changing insn?  How about jump insns?  How about
insns that are SETs, or PARALLELs containing at least one SET?  Does
anyone see any risk in recognizing those when the length attr is,
conservatively or not, deemed unreliable?  Any other paterns we could
recognize to that end?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


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