View Issue Details

IDProjectCategoryView StatusLast Update
0036060FPCCompilerpublic2019-09-10 17:31
ReporterKai BurghardtAssigned To 
Status newResolutionopen 
Platformx86_64OSGNU/LinuxOS Version4.2.0
Product Version3.0.4Product Build3.0.4+dfsg-11 [2017/12/30] 
Target VersionFixed in Version 
Summary0036060: empty ansistring check with length() is more complicated
DescriptionI wondered, whether someString = '' or length(someString) = 0 is “better”. Turns out, only the former produces a cmp-vs.-zero instruction.
Steps To Reproduceprogram emptyStringCheck(input, output, stdErr);
{$longStrings on}
    someString: string;
    someString := '';
    if length(someString) = 0 then
        writeLn('Great. Now I don’t know what to say.');
    // just for comparison:
    if someString = '' then
Additional InformationThe length check becomes (on a x86 target):

# [7] if length(someString) = 0 then
        testq %rax,%rax
        je .Lj13
        movq -8(%rax),%rax
        testq %rax,%rax

First, we ensure someString isn’t a null pointer. OK.
But then it already becomes strange: We check again for zero (the testq after je .Lj13)?
I mean, I understand -8(%rax) dereferences the non-nil-pointer and retrieves the length field _in_ _front_ _of_ the first character (which an ansistring variable points to).

But why is that so complicated?
Tagscompiler, optimization, String
Fixed in Revision
Attached Files


Thaddy de Koning

2019-09-10 07:27

reporter   ~0118013

Simply because you explicitly ask it to perform the length() intrinsic in the first example, whereas the second example directly checks for empty

Kai Burghardt

2019-09-10 13:12

reporter   ~0118017

Well, I can apply that argument to the second example, too:
I explicitly ask to perform an = comparison, but I find no call to fpc_ansistr_compare_equal in the generated code.

Thaddy de Koning

2019-09-10 17:30

reporter   ~0118018

Last edited: 2019-09-10 17:31

View 2 revisions

No (at least partially) expressively asking for length needs to be evaluated.
I see the point, btw, but it is simply not optimal and it will likely never be.

Issue History

Date Modified Username Field Change
2019-09-09 22:52 Kai Burghardt New Issue
2019-09-09 22:52 Kai Burghardt Tag Attached: optimization
2019-09-09 22:52 Kai Burghardt Tag Attached: compiler
2019-09-09 23:00 Kai Burghardt Tag Attached: String
2019-09-10 07:27 Thaddy de Koning Note Added: 0118013
2019-09-10 13:12 Kai Burghardt Note Added: 0118017
2019-09-10 17:30 Thaddy de Koning Note Added: 0118018
2019-09-10 17:31 Thaddy de Koning Note Edited: 0118018 View Revisions